Precomputed and transactional mixing

ABSTRACT

Precomputed and transactional mixing is believed to allow portable devices, such as smart phones, to send and receive messages, with little extra bandwidth or battery usage, while achieving anonymity for senders and recipients among all messages sent globally in batches defined by short time intervals. To learn anything about which inputs correspond with which outputs of such a batch of messages, the entire cascade of mix devices, each preferably operating independently in a different country, would it is believed have to be compromised.None of the real-time computation, neither by the mixes nor smartphones, uses full public-key operations - - - resulting it is believed in orders of magnitude performance improvement over previously-known systems.Aspects include untraceable return addresses, group chat, feed-following and large payloads. Transaction protocols include a variety of payments use cases. Limited anonymity and credential mechanism are based on a new approach to user identification disclosed, in which each user provides a small amount of different identifying information to each mix node, so that comparatively little is revealed to each node individually.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. ProvisionalApplication No. 62/133,456, entitled PRECOMPUTED AND TRANSACTIONALMIXING,” (EFID 21771858, confirmation number 3691, filed 23:07:33),filed Mar. 15, 2015, the entire contents of which are incorporated byreference herein and as if copied in their entirety.

FIELD OF THE INVENTION

This invention relates to cryptographic apparatus and systems and morespecifically to those aimed at securing communications and transactions,including protecting traffic data that allows tracing related to whocommunicates and transacts with whom.

BACKGROUND OF THE INVENTION

Mix networks have been the subject of significant research, commercialactivity, and actual use since they were first disclosed by the presentapplicant in 1979. Such prior art mixing, however, generally performspublic-key cryptographic processing on messages as they travel throughthe network. This is believed to result in significant commercialdisadvantages in terms of efficiency and efficacy relative to thepresent invention. Moreover, use of mix networks has been limitedlargely to providing unlinkability of communication, whereas aspects ofthe present invention not only extend mixing's protections totransactions but also offer other types of protections that addressbroader needs of communication and interaction of users.

Novel cryptographic apparatus and methods disclosed here allow mixingthat is believed significantly more efficient in terms of the amount ofcomputation performed in realtime and consequently allow reduction bothin overall delay of messages and cryptographic processing capacity. Thisis of commercial significance at least because it is believed thatefficiency has limited the adoption as well as the efficacy of, andrelates to the cost of, mixing systems both used and proposed. It isalso believed of commercial significance because delay through each of anumber of stages of mixing adds up, which tends towards more batches,use of less stages, reduced protections for users, and consequently lessattractive offerings to users. The improved efficiency is believedfurther of commercial significance because it improves the reducedutilization and related hardware cost of cryptographic processing ofprior art schemes. Moreover, users are believed sensitive, especiallywith increasingly popular portable devices, to computation time andenergy usage. Also, some prior-art mixing has been based on strongerassumptions about underlying cryptographic primitives and thus may bemore vulnerable to cryptanalytic attack.

In brief non-limiting summary some exemplary embodiments of someinventive aspects will now be provided. A so-called “cascade” or seriesof n mix devices, called here “nodes,” receives b messages, each messageassociated with a corresponding entity/device here called a “user,”“user device,” or “subscriber.” Included in the messages are encryptionsformed by the subscribers. In what may here be called an “unpermuted”phase, each mix node processes these b inputs into what here may becalled a “normalized” form, using non-pubic information held in commonpairwise by nodes and corresponding subscribers, and typically employinga mathematically commutative property. Then in what may here be called a“permuting” phase, each of the b messages is transformed successivelythrough each of the n nodes, during which the encryption remaining afternormalization is removed and each node permutes the order of the binputs it processes. The output of the cascade contains the b messagessent by potentially identified subscribers but in an order believedunpredictable to any proper subset of non-colluding nodes.

For clarity a particular non-limiting but concrete example will bedescribed using modular exponentiation as the encryption, first withoutpre-computation and including successive processing in the unpermutedphase. Each of the b messages is sent by a distinct subscriber, each ofwhich has established a different secret key in common with each of then mix nodes. A subscriber raises its actual message content c to thepower computed as the product of the secrets that subscriber shares withall the nodes, in a group where discrete log is at least believed hard.Then, in an unpermuted phase, each node successively normalizes byraising to a computed secret power that both cancels the uniquesubscriber power and leaves in place a single round secret power thatnode uses for all messages in the batch. In the permuting phase, eachnode permutes the b messages it receives from the preceding node in thecascade and raises each message in the batch to a power that cancelsthat node's single round power, so that the final output batch containseach original message content c unencrypted but re-ordered by thecomposition of the permutations applied by the successive nodes.

In an exemplary simplified non-limiting pre-computation embodimentdescribed for clarity, the nodes first cooperate to produce a so-called“shared public key” for homomorphic encryption, such as one thatincludes independent private keys from each node. The nodes then ineffect go through the motions of the two real-time phases alreadydescribed, unpermuted and permuted, but instead of encrypting a messagepayload they homomorphicly combine keys injected at each stage, the samekeys that will be used again at the corresponding stages of the realtimeprocessing. The final accumulation of individual keys that apply to aparticular position in the overall output of the cascade is thenrecovered by the nodes cooperating in decryption of the homomorphicencryption for that output position. Inputs for realtime processing canuse the same group operation as that of the homomorphic encryption, sothat the set of key group elements that are combined by the groupoperation with the message to encrypt the message payload in the outputcan be cancelled by combining with the inverse of what is recovered bydecrypting the final result of the homomorphic encryption.

In some exemplary non-limiting functionality extensions, believedadaptable for mixing more generally, message types and protocols fortheir use are disclosed allowing applications such as, encrypted email,untraceable return addresses, polling/anti-spam, credential mechanisms,and payments including so-called “payer anonymity.” The novel unpermutedphase of processing, with pairwise secured communication betweensubscribers and nodes, allows nodes to optionally at least partlyindependently verify aspects of user identity and various transactionparameters.

Prior Art Mixing

Mixing was first proposed by the present applicant in a June 1979University of California, Berkeley technical report that was submittedfor publication that year under the same title and then appeared as“Untraceable electronic mail, return addresses, and digital pseudonyms,”1981 Communications of the ACM, February 1981, vol. 24 no. 2, pp 84-88.

Included in this prior art was the notion of so-called “hybrid”encryption: that keys could be provided by public key techniques thatcould then be used for non-public key encryption of additional messagepayload. Some more recent systems have used such conventional keys forsubsequent communication through the same set of mix nodes; however, usebeyond the original message begins to erode untraceability, since allsuch uses are linkable by all nodes and traffic patterns link these tothe user and the other parties that the user communicates with as wellas the times and volumes of communication.

Inventive aspects of the present application retain the unlinkability asin the original proposal, white they may be able to only use groupoperations for encryption during transmission of messages, instead ofany of the typically far more computation/data-intensive full public-keyoperations.

The approach to identification of users of an informational system thathave been taken in the prior art are believed to be roughly divisible inthe main between two alternatives: unchecked user identity or monolithicsecurity model for identity checking. It will be appreciated thatsystems that do not check user identity are subject to various kinds ofabuse, including the use of many identities by a single person andreduced accountability; however, what have been called “reputation” and“credential mechanisms” can potentially overcome some of thesedisadvantages. Unchecked systems are believed to have the unfortunateproperty that those few who may make the most serious abuses may takethe strongest measures outside the system to remain untraceable, whereasmost users of the system may be comparatively easier to link to theiruses.

In a monolithic identification system, there is mainly a singleauthority that the user is to satisfy as to the adequacy of the user'sidentification. One believed kind of disadvantage of such an approach isthat a single entity amasses information about a person that may allowthat entity to link to aspects of a person's activities beyond thecharter of the system, and in case of compromise of that single entitymakes the person vulnerable to impersonation. Another type ofdisadvantage is that the authority may, in some cases, dilute theefficacy of the system by providing exceptions to certain persons. Wellknown examples include celebrities, witness protection, intelligenceoperatives, internal personnel, and administrators.

There are variations on the monolithic approach to identity checkinginvolving the legal “structuring” of entities. For instance,identification checking subcontractors may be employed by a monolithicentity. As another example, so-called “federated” identity schemes alloworganizations to benefit from identity checking performed by a centralauthority or by another organization member of the federation.

The believed novel approach to identification taken in some aspects hereallows each node to form their own independent identity verification forthe user such that only if the user is accepted separately by each ofplural nodes is the user accepted by the system. A believed advantage ofthe approach is that while users may be reluctant to share a lot ofidentifying data with a single entity, it is believed they may be morewilling to share that same amount or even more data when it is dividedinto separate parts with respective separate entities, especiallyentities under separate jurisdictions and/or when entities are not toshare the data. Another example believed advantage of the approach isthat false identities may be harder to inject into a system as thenumber of entities that would need to be deceived and/or corrupted tocreate a false identity.

Untraceable communication systems have been considered infrastructurefor transaction systems. As just one example, such an approach wasproposed for payments and credential mechanisms in, “Achievingelectronic privacy,” by the present applicant, Scientific American,August 1992, p. 96-101. In some few examples, mixing has alternativelybeen considered as a component for a larger system, such as in anelection system or in processing payment orders already approved.

Inventive aspects of the present system advantageously integratetransactions with the mixing communication infrastructure. This isbelieved to, for one thing, potentially increase the amount of trafficin the underlying system and thereby increase the privacy protectionoffered. As another example, it is also believed to benefit users by theintegration of services and adoption by the bundling of services.Moreover, it is believed that there are significant technical economies,such as in terms of key management, computation, infrastructure, systemadministration, and so forth. More fundamentally, the security modeland/or arrangements of the communication system can be applied to thetransaction systems as well.

General Description

Several related general aspects are disclosed here without anylimitation.

Examples of mix cascades may be described for concreteness and clarityusing two nodes, for example, but it will readily be understood andappreciated that any number of nodes may be used. Similarly, in someexamples every user may send a single message per batch; in otherexamples, each user may send more than one message in some batches; andmore generally, each user may send zero or one or more messages perbatch and in a way that differs per batch.

The keys known to pairs made up of a user and a node are referred to as“common” keys or keys that are “common” to the pair. Common keys areoptionally used also for authentication of input messages, such as byso-called MAC's. In some examples a subset of nodes may be sufficient toauthenticate the MAC's.

For some commutative encryption functions, such as the well-knowndiscrete log, composition of a series of encryptions can be computedalmost as efficiently as a single encryption, using knowledge of thepublic order of the group to reduce the size of the exponent.

More flexible flows are anticipated, such as if the mixing of inputsproceeds in sub-batches, sliding windows, and/or probabilisticly. Asjust one non-limiting example, each node could delay an item from onebatch to a next according to some probability distribution associatedwith that node and/or other factors in system operation. As another suchexample, each node could delay each message some amount of time chosenfrom a suitable distribution.

Proof or auditing that the mixes perform their mixing transformationscorrectly may be provided, for instance, by multiparty computationtechniques, as are known in the art.

For an exponentiation-based system, such as without pre-computation, anexample is where it is believed that a mix can “prove” that it hasraised each input item to the same power in the realtime phase. Forinstance, a so-called “challenge” may be formed as set of exponents; themix publishes a value; and a binary choice is made between the mix beingrequired to provide the power that takes that product of powers of theinputs to the published value or the power that takes the product ofpowers of the outputs to the shared published value. Such a procedurecan be repeated for more certainty and the choice of exponents can bereduced and the number of repeats increased. An example reduces theexponents to zero and one, in the case when the number of repeats may beon the order of one hundred.

As an example of proofs believed suitable for a pre-computation system,a subset of the messages, such as in the input and/or output can beselected by a multi-party secure method as are known and those messagesopened all the way through the cascade. This can be done at thepre-computation stage to detect deviation from protocol at that stage.Unpermuted phase processing can, for example, be checked by sendersbecause they can inspect the order-preserving transformations of theirinputs in the unpermuted phase processing. During a permuting phase,nodes can use commitments they already published in an auditedpre-computation phase as part of their proofs. For instance, apre-computation publication of quotients for each pair of input andoutput item that are in the same position in the ordering (i.e, firstinput to first output, second input to second output, etc.) allowschecking of the mix processing from the published data and datacommunicated between nodes.

It may be desired to have so-called “forward secrecy,” a term that isbelieved applied to a variety of properties in the art. Persistentshared-keys are believed best transformed in an irreversible manner foreach transmission, so as to prevent earlier messages from beingcompromised by any subsequent leak of key state. By conducting keyagreement protocols from time to time, which is believed also desirable,even compromised persistent keys only reach forward till the nextagreement protocol. Furthermore, by including persistent state in withthe agreement protocols, an adversary capable of breaking such agreementprotocols may be thwarted.

The non-permuting phase can be so-called “pipelined,” by dividing theinput into separate portions that are each processed by a differentordering of the nodes, as will readily be understood. This lets eachnode process at more or less a so-called high “duty cycle,” as there areno major forced time delays during which a node cannot be processing.Pipelining of the permuting phase in a similar manner, as will beunderstood, it is believed would divide the input into portions thatcould, depending on parameters, be linked to corresponding portions inthe output—thereby reducing unlinkability. Pipelining the mix phase fora first half of the nodes and then providing the output of this as inputto a pipeline for a second half of the nodes is believed to improveunlinkability over a single pipeline. This can be generalized topipelines of distinct or overlapping nodes with whatever multiplicity.

In some further non-limiting examples of pipelining of the permutingphase, the division into separate portions may not be public but insteadknown to each respective node. For example, each node can be assigned a“random” or “unpredictable” subset of the inputs to start thecorresponding sequential processing. In some examples, the nodes canperform a multiparty computation to assign these portions withoutsubsets of nodes knowing more than their own subset partition. Forinstance, one example type of multiparty computation to accomplish thiscan use the system itself to process inputs provided by each node andthe position of those in the lexicographically sorted output, known andrecognizable by a node, would be that node's portion.

As for the pre-computation phase, pipelining may be applied in a varietyof ways. For instance, multiple pre-computations can be conducted inparallel and in advance of when they would actually be deployed. Otherexamples will be described later, such as with reference to FIG. 7.

There may be various input structures, such as buffers, routers,forwarders, aggregators, front-ends and the like that feed early partsof the processing; nevertheless, the input device may be considered thefirst node of the unpermuted phase processing without any loss ofgenerality. Similarly, there may be various output buffering,forwarding, or delivery structures and processes that feed the resultsof the second phase of processing to other entities; nevertheless, thelast node of the unpermuted phase processing may be considered theoutput device without any loss of generality. In some examples where alive phase uses non-sequential processing before the permuting phase, afront-end processing capability may provide information to the nodesabout the identity of the entity supplying a message input and the inputslot of the mix that message will occupy. The nodes may then supply theresulting contributions for aggregate application by the entityperforming front-end processing. Further examples are described withreference to FIG. 7.

In some yet still further non-limiting examples mentioned, nodes docomputation in advance of the processing of input, as what generally maybe referred to here as a “pre-computation,” ideally so that the realtimeprocessing of input is sped and/or otherwise enhanced and/or moreefficient use is made of computing resources. As just one example, apre-processing can provide each node with enough data that thecommutative operations can be what is sometimes regarded as“non-cryptographic” or “non-complexity-based”; as an example, in theabsence of, for instance, an exponentiation with secret exponent as thecommutative operation such examples can instead use a group operation inthe group by secret values each ideally appearing in a form visible toan attacker only once. This is related to what is sometimes referred toas a “one time pad” type of arrangement, or a system where among otherthings the number of key values revealed is the same as the total numberof values known to the adversary. It will be understood by those ofskill in the cryptographic art that such key values can be arrived at inprinciple by a multiparty computation between the nodes.

It is believed that a pre-computation may in some examples processmessages through nodes in the same order as the live phase or, in otherexamples, in the opposite order as the live phase. When processed in thesame order, the result of the homomorphic operation may be applied atthe end of the live phase; when processing in the reverse order, theresult of the homomorphic operation may be applied at the beginning ofthe live phase, subsequent to normalization.

The input to the backwards run may be taken as a known constant vector,for instance a random vector, or what is believed more conveniently, theidentity vector. The last node in the forward run, the first in thebackwards run, permutes this vector using the inverse of the permutationthat will be used in the forward run, which it effectively retains atleast the ability to reconstruct. This node chooses and retains at leastthe ability to reconstruct a vector of random values and multiplies eachof the permuted values by, for clarity, what may be regarded as themultiplicative inverse of the respective random value retained. Thepenultimate node in the forward order, adjacent this already describednode, takes this resulting pre-computation vector as input from thealready described node and processes its elements in this same way, withits own choice of retained values and permutation, so that they can beprovided to the node that is its predecessor in the forward order. Thiscascade processing proceeds in this reverse order, as will readily beunderstood, through to and including the first node of the forward-ordercascade. From this point to the overall input vector, as the reversepremix, each node successively processes the resulting vector from itspredecessor in reverse order in a similar manner, ideally withessentially independent random values retained, but with the identitypermutation.

The pre-computations just described may be encrypted using a so-calledpartially homomorphic cryptosystem, such as for instance the well knownEl Gamal system. In this example, the nodes can compute a so-called“shared” public key, such as by each successively raising the result ofsuch key generation by the preceding node to its own secret-key power;the result is the agreed generator raised to the product of the privatekeys of the nodes, as will readily be understood by those of skill inthe cryptographic art. The final vector of values encrypted with thisshared key can be decrypted by the nodes each successively applying theinverse of the secret power to each element of the vector. The elementsof this decrypted vector are then combined by the group operation withthe respective input items of the input vector before it is processed inthe forward direction in the manner already described above.

Sending through this example pre-computed system, instead ofexponentiating, a user includes, using the group operation, a groupelement corresponding to each node. The element can, for instance, becryptographically dependent on a secret key common to the user and thenode, much as in the systems without pre-computation already described.Each of these elements will be understood to be cancelled by thecorresponding node during the non-permuting processing; however, a newelement, from the pre-computation phase, will be substituted by the nodeto replace each element as it is cancelled in the non-permutingprocessing. Thus, the user-supplied elements will all be cancelled andthe pre-computed elements will all be included as the realtimeprocessing moves forward from non-permuting through to permuting. Sincethe element that was included from the final vector of values encryptedwith the shared key is the inverse of the product of all the elementsfrom the pre-processing for a particular input, and these will bemultiplied in during the forward direction processing for that input asit appears in corresponding positions in the intermediate vectors, kepttogether under the permutations, it is believed as will be appreciatedthat all the pre-processing terms will cancel, leaving the originalcontent element in the output vector.

In some settings it is believed advantageous to allow users to send manymessages but to allow messages that have a unique occurrence per user tobe recognized as such. One example use, for instance, would be inelections or statements of opinion on a particular issue, where a userstatement would have more weight if it were known to be the uniquestatement of a user related to the particular issue, even though whichuser made the statement remains hidden. An example way to achieve suchfunctionality sends pairs of messages, such as even and odd positions inthe input vector, one message providing the uniqueness for the payloadcontained in the other message. Such a uniqueness message can beprocessed by the nodes using a fixed transformation per user in thenon-permuting phase; the changing transformations described elsewherehere for the non-permuting phase would still be used for the payloadcarrying message of the pair.

In some settings it may be desired to provide robustness in case somemix nodes fail or otherwise leave the system. In one example approach tosuch robustness nodes use so-called “verifiable secret sharing” toprovide shares of their keying material so that in their absence aquorum of other nodes can recover the keying material, as is known.So-called “secret sharing” techniques or those proposed earlier by thepresent applicant using various combined encryptions to achieve similarbut more general results can be applied.

In some settings it may be desired for the nodes to selectively tracecertain messages back to their origin. Such tracing is possible if thenodes retain suitable records or otherwise access to earlier processing.

What will be called here “shared-key homomorphic cryptosystems” areknown. In such systems each of a number of parties can cooperate tocreate what may be called here a “shared public key,” which is in effectinformation that defines an encryption operation that at least eachparty can use to encrypt an input value. Encryptions formed with theshared public key operation can be combined with a group operation,typically addition or multiplication, such that the parties cancooperate to decrypt the combined encryptions and the resultingcleartext is equivalent to the input values combined by the groupoperation.

This homomorphic property may be shown as h(r₁)h(r₂) equals h(r₁r₂),where anyone can apply h to encrypt using the shared public key; butcooperation of the parties can invert h or decrypt by computation of theinverse h⁻¹.

An illustrative example, without any limitation whatsoever and forconcreteness and clarity, is what is believed to be a multiplicativeshared-key homomorphic cryptosystem, based on the encryption operationof the well known so-called “El Gamal” cryptosystem. This cryptosystemuses a multiplicative group where discrete log is assumed hard andencrypts each value using a random value and public key.

It is believed that such example systems can be implemented in whatevergroup where the so-called property “discrete log is hard” holds, whichis currently believed to include for example arithmetic modulo a largeprime, such as a one thousand or two thousand bit prime, particularly aso-called “safe” or even a “strong” prime. It is further believed thatnot all elements of such groups are generators but that the structure ofthe cyclic group allows elements chosen from the whole group uniformlyto hide other such elements in products; alternatively, however,elements could be restricted to a subgroup where all elements aregenerators, such as the quadratic residues.

The following example shows for clarity the use of such a system by twoparties, each encrypting its own secret value, forming the product ofthe encryptions, and decryption of the product by cooperation of theparties; however, extension to any number of parties and any number offactors will readily be understood:

“definitions”:

g:=Agreed generator of multiplicative group in which all arithmetic(except that in the exponent) is shown, where group operation isrelatively efficient and discrete log is hard.

x,y:=Secret exponents of nodes X and Y, respectively.

g^(x),g^(y):=Public keys of X and Y, respectively.

a,b:=Temporary secret exponents of X and Y, respectively.

r_(x),r_(y):=Secret elements of X and Y, respectively, whose product isrevealed in the homomorphic decryption.

“shared-key set up”:

X and Y form and make public

g^(xy), by X revealing g^(x)

(which is the public key of X)

and then Y revealing

(g^(x))^(y).

“homomorphic encryption”:

X reveals the El Gamal pair (g^(xya), r_(x)g^(a));

Y reveals the corresponding pair (g^(xyb), r_(y)g^(b)); and then

everyone can compute the component-wise product of the two:

(g^(xya)g^(xyb), r_(x)g^(a)r_(y)g^(b))=(g^(xy(a¬b)), r_(x)r_(y)g^(a+b))

“homomorphic decryption”:

X reveals g^(y(a+b)),

by decrypting first component of step 2; and then

Y reveals g^((a+b)); and then everyone can compute

r_(x)r_(y) from the second component of step 2.

FURTHER BACKGROUND OF THE INVENTION

The following claim like language is copied from the application fromwhich priority is claimed as mentioned above:

(a) Message transport apparatus for delivering messages from an inputdevice to an output device, comprising: An input device receiving pluralmessages, each such message identified as related to at least one of aset of common keys; Plural first phase processing devices, each privy toplural common keys and each applying a transformation to messagesreceived responsive to a corresponding one of the common keys andincluding the transformation related to a key corresponding to at leasta second phase processing device; Plural second phase processingdevices, each receiving at least some messages processed by the firstphase processing devices and each further processing messages byre-arranging the order of messages substantially unpredictably andapplying transformations responsive at least to values known torespective second-phase processing devices; and Such that the order ofthe items received by the input device substantially different from theorder of items output by the output device, and the linking betweenitems in the input and items in the output hidden from those withoutknowledge of the values known to the devices.

(a1) The apparatus of claim a, including a third phase withoutpermutations and processing related to the third phase using keys commonto recipients of messages.

(a2) The apparatus of claim a-a1 [to be read throughout these claims asthe present claim is multiply dependent on all claims from claim “a” toclaim “a1,” inclusive, with method/apparatus/system language adapted asmay be understood], including:

A pre-computation phase during which said processing devices developkeying values responsive to permutations of their respective inputs andinvertible transformation of such inputs later decrypted by cooperationof the processing devices; and where the first phase and the secondphase processing are responsive to the values developed during thepre-computation phase and the second phase responsive to thepermutations developed during the pre-computation phase; and thecomputation performed during the combination of the first and secondphases is substantially reduced by the pre-computation phase.

(a3) The apparatus of claim a-a2, comprising: the first and second phaseprocessing devices arranged so that at least one first first-phaseprocessing device is substantially the input device and at least onelast second-phase processing device is substantially the output devicefor at least some messages.

(a4) The apparatus of claim a-a3, such that each of plural messages sentby the same user are unlinkable in the output.

(a5) The apparatus of claim a-a4, including at least one first phaseprocessing device [sic] and a second phase processing device.

(a6) The apparatus of claim a-a5, including the pre-computation phaseincluding keying values transformed by the permutations used in thesecond phase.

(b1) A cryptographic system for a set of nodes substantially to hide thecorrespondence between at least a set of inputs supplied to the nodes bysubscribers and a responsive set of outputs developed by the nodes,comprising the steps of: Nodes apply a first permutation in a firstprocessing for a first batch; Nodes apply a permutation related to thefirst permutation in at least a second processing for a second batch;Nodes transform first messages related to the first processing; andNodes transform second messages related to the at least secondprocessing.

(b2) A cryptographic system for a set of nodes substantially to hide thecorrespondence between at least a set of inputs supplied to the nodes bysubscribers and a responsive set of outputs developed by the nodes,comprising the steps of: Nodes apply a first permutation in aprecomputation for a first batch; Nodes apply a permutation at leastrelated to the first permutation in at least a second precomputation fora second batch; Messages are transformed by the nodes in a firstprocessing using the first permutation; and At least indications areprocessed by the nodes in at least a second processing using the secondpermutation related to delivery of the output of the first processing.

(c) A cryptographic method for a set of nodes substantially to hide thecorrespondence between at least a set of inputs supplied to the nodes bysubscribers and a responsive set of outputs developed by the nodes,comprising the steps of: Establishing common first keys by nodes thatare in common with subscribers; Accepting by at least one node ofsubscriber submitted encrypted input items including encryption withkeying responsive to the common first keys;

An unpermuted phase wherein the common first key aspects of items arereplaced with node second keys known to respective nodes; A permutingphase wherein said node second keys are cancelled and the itemsre-arrange; and So that the relative arrangement of the input and outputitems is substantially unpredictable to those without knowledge of thecommon first keys, the permutations, and node second keys.

(c1) The method of claim c, including: A pre-computation phasedeveloping values responsive to permutations of respective inputs andinvertible transformation of such inputs, where the non-permuting phaseand the permuting phase processing are responsive to the valuesdeveloped during the pre-computation phase; and the computationperformed during the combination of the non-permuting and permutingphases is substantially reduced because of the pre-computation performedin the pre-computation phase.

(c2) The method of claim c-c1, including: each payload message pairedwith a uniqueness message; the first phase processing of the uniquenessmessages the same across instances; the uniqueness messages in the inputbeing enforced as unique per user; and so that the uniqueness message inthe output are unique per user and are substantially unlinkable to theinput uniqueness messages.

(c3) The method of claim c-c2 including: payload messages beingassociated with a re-blinded form of at least a master credential peruser.

(c4) The method of claim c-c3 including: payload messages includingprovision for transfers of value between accounts where authenticationis included in payloads for source accounts.

(c5) The method of claim c-c4 including: payload messages includingprovision for an exception to be raised if a withdrawal transactionfails to be consummated and the exception being linked to acorresponding input withdrawal message type.

(c5.1) The method of claim c5 including: transfer payloads resulting inconfirming messages.

(c6) The method of claim c-5.1 including untraceable return addresses.

(c7) The method of claims c-c6 including: a third phase encryptingmessages with the respective common key of the intended recipient.

(d1) Apparatus or system claims a-c, including plural users formingmessages supplied for input processing.

(d2) Apparatus or system claims a-d1, including proofs by nodes that theprocessing is correct.

(d3) Apparatus or system claims a-d2, including forward secrecy on atleast some keys in common between nodes and subscribers.

(d4) Apparatus or system claims a-d3, including authentication checkableby nodes using at least some keys in common between nodes andsubscribers.

(d5) Apparatus or system claims a-d4, including a broadcast of messagesto nodes during the non-permuting phase.

(e) A mix method or apparatus comprising plural entities receivingencrypted input items in a first order and producing as output at leastdifferently encrypted items in a second order, such that therelationship between the orderings is at least difficult to predictwithout secrets of at least a quorum of the plural entities.

(e1) The mix of claim e including: each payload message paired with auniqueness message so that the uniqueness message in the output isunique per user and substantially unlinkable to the input uniquenessmessages.

(e1.1) The mix of claim e1 including: so that the user can substantiallychoose the uniqueness message.

(e1.2) The mix of claim e1.1 including: so that the user cansubstantially choose the uniqueness message.

(e1.2) The mix of claim e1.2 including: so that the uniqueness messageincludes a count.

(e1.3) The mix of claim e including: a payload message paired with adesignator so that the designator in the output substantially unlinkableto the inputs and substantially unpredictable to users and substantiallyrepeatable by any user supplying the same designator in the input.

(e2) The mix of claim e including: payload messages being associatedwith a re-blinded form of at least a master credential per user.

(e3) The mix of claim e including: payload messages including provisionfor transfers of value between accounts where authentication is includedin payloads for source accounts.

(e4) The mix of claim e including: payload messages including provisionfor an exception to be raised if a withdrawal transaction fails to beconsummated and the exception being linked to a corresponding inputwithdrawal message type.

(e5) The mix of claim e including: encrypting messages with therespective common key of the intended recipient.

(e6) The mix of claim e including: providing an authentication of thesender to the recipient of the message.

(e7) The mix of claim e including: decrypting messages by nodes with therespective common keys of senders.

(e8) The mix of claim e including: at least some of the output itemsassociated with persistent pseudonym information that remains the sameacross at least some output items from the same sender.

(f1) A cryptographic system for a set of nodes substantially to hide thecorrespondence between at least a set of inputs supplied to the nodes bysubscribers and a responsive set of outputs developed by the nodes,comprising the steps of: Nodes apply a permutation in processing a firstbatch; Nodes apply the same permutation in processing at least a secondbatch; Messages are transformed by the nodes related to the firstprocessing using the permutation; and Messages are transformed by thenodes related to the at least second processing using the samepermutation.

(f2) A cryptographic system for a set of nodes substantially to hide thecorrespondence between at least a set of inputs supplied to the nodes bysubscribers and a responsive set of outputs developed by the nodes,comprising the steps of: Each of multiple nodes applies in a first ordera first permutation in processing a first batch from plural senders;Messages of the first batch so processed delivered to respectiverecipients; Each of the nodes in the reverse of the first order appliesan inverse of the first permutation in processing at least a secondbatch; and At least indications related to the respective messages anddestinations processed as the second batch and provided to at least aportion of the respective senders.

(g) A multi-server private information retrieval system, the improvementcomprising: each of multiple servers each shares two separate keystreamswith each user device; at least one of the first keystreams is suppliedby the user device to at least one of the servers; each server combinesitems inverted responsive to a corresponding first keystream of the userdevice by a group operation to produce a pre-output; each servercombines the pre-output with the respective second keystream from theuser device by a group operation to produce a respective encryptedindividual server output; servers cooperate to combine individualencrypted server outputs by related group operations to produce acombined server output; and the combined server output is supplied tothe user device.

(g1) The retrieval system of claim G, including: a server hubbroadcasting all items to multiple server front-end processors; and atleast one of the server front-end processors combining, using a groupoperation, items broadcast, inverting items corresponding to said firstkeystream known to that front-end processor.

(g2) The retrieval system of claim G or G1, including said user devicepublishes untraceably a list of feed identifiers and receives a positionindication.

(g3) The retrieval system of claim G, G1 or G2, including: a user deviceencrypting a data item, sending it for posting and obtaining anidentifier for the posted encrypted item; the user device sending amessage to at least one desired recipient of the data item, the messageincluding keying information to allow decryption of the item and theidentifier for the posted encrypted item; and the recipient using arespective device to send a keystream to a selected server with adesired position selected responsive to the identifier received.

(h) In a mixing system, the improvement comprising: an establisherentity forming mix-stage keys and providing each of plural mix nodeswith a respective different one of the keys as a payload of acorresponding establishing mixing, one such establishing mixing for eachmix-stage key; the mixes in each establishing mixing cooperating to mixthe keys so that a corresponding mix receives the respective mix-stagekey and the key, and the correspondence between sender and key,substantially kept from other mixes; a sender entity, optionallydistinct from establisher entity, successively processing, where theprocessing is selected from the group including encrypting ordecrypting, a payload using the mix-stage keys, as a layer, andincluding along with the layer a fingerprint of the respective mix-stagekey used with each such successive layer and providing the result to atleast a first mix; at least a first mix receiving at least a partiallysuch successively processed payload and the at least first mix locatingthe mix-stage key received earlier by matching the fingerprint of thekey with the associated key previously received and then using thelocated key to process, where the processing is selected from the groupincluding encrypting or decrypting, the layer and forward the result asan output; and at least a second mix receiving at least the output of atleast an earlier mix and locating the mix-stage key received previouslyby matching the fingerprint of the key with the associated keypreviously received and then using the located key to process, where theprocessing is selected from the group including encrypting ordecrypting, the layer and to forward the result to a receiving party.

(i) In a mixing system, the improvement comprising: nodes creating acoordinated component for a message during an unpermuted phase thatincludes values representing unique cryptographic functions of thesender identity, so that the sender identity results in a unique valueunpredictable to other than the nodes; nodes process the created messagealong with plural components during a permuting phase and optionallyincluding respective values representing substantially cryptographicfunctions of the recipient of the message, so that the resultingpseudonym is a substantially unique value corresponding to the senderrecipient pair and substantially unpredictable other than to the nodes;and nodes processing the created message along with the othercomponent(s) and revealing the combination of created values in outputof the mixing system, whether public or delivered privately to arecipient.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1, shown is a combination block diagram and cryptographic protocolschematic of a mix without pre-computation in accordance with aspects ofthe teachings of the present invention.

FIG. 2 is a combination block diagram and flowchart of a mix withoutpre-computation, shown in accordance with aspects teachings of thepresent invention.

FIG. 3 shows an exemplary combination block diagram and cryptographicschematic of a precomputation mix is shown in accordance with aspectsand teachings of the present invention.

FIG. 4 shows a flowchart of exemplary pre-computation mixing inaccordance with aspects of the teachings of the present invention.

FIG. 5 presents a combination block diagram and cryptographic schematicof a pipelined unpermuted phase described in accordance with aspects andteachings of the present invention.

FIG. 6 shows an example broadcast unpermuted phase in combination blockand cryptographic schematic, in accordance with aspects and teachings ofthe present invention.

FIGS. 7A and 7B shows flowcharts of pipelined and star unpermuted phasesin accordance with aspects of the teachings of the present invention,with FIG. 7A relating to the pipelined configuration already describedwith reference to FIG. 5 and FIG. 7B relating to the star configurationdescribed already with reference to FIG. 6.

FIGS. 8A and 8B show combination block diagrams and cryptographicschematics of exemplary authentication from users to nodes are shown inaccordance with aspects and teachings of the present invention, withFIG. 8A relating to the subscriber identification and explicitauthentication provided nodes by subscribers shown in FIG. 1 and withFIG. 8B relating to FIG. 3 shown with subscriber identification andexplicit authentication provided to each node.

FIG. 9 is a flowchart for exemplary authentication aspects in accordancewith aspects and teachings of the present invention.

FIGS. 10A and 10B show combination block and cryptographic schematicdiagrams for basic single and multiple message block sending inaccordance with aspects and teachings of the present invention, withFIG. 10A related to the sending of a single block message and FIG. 10Brelated to sending of an example of two messages that are linked atoutput and forming a single concatenated message.

FIG. 11 is a flowchart depicting multiple message block sending inaccordance with aspects and teachings of the present invention.

FIGS. 12A and 12B, are combination block and cryptographic schematicdiagrams for untraceable return addresses in accordance with aspects andteachings of aspects of the present invention, with FIG. 12A relating tothe establishing of an untraceable return address and FIG. 12B relatingto the sending of a message using such an untraceable return address bya sender directing the message to the creator of the untraceable returnaddress, even though the identity of the creator of the untraceablereturn address is unknown to the sender.

FIG. 13 is a return address sending flowchart in accordance with aspectsand teachings of the present invention.

FIGS. 14A, 14B and 14C are combination block and cryptographic schematicdiagrams for limitation of multi-sending in accordance with aspects andteachings of the present invention, with FIG. 14A related to thelimitation to a single sending of a particular type per user, FIG. 14Brelated to the indication being determined in a way that at least theuser cannot readily guess what it will be or control what it will be,and 14C related to designators repeated across users when parameters arerepeated by users.

FIGS. 15A and 15B are flowcharts for limitation of multi-sending andother encrypted payloads in accordance with aspects and teachings of thepresent invention, with FIG. 15A related to the operation according toFIG. 14A and FIG. 14B, as already described, and with FIG. 15B relatedto those of FIG. 14C.

FIGS. 16A and 16B are combination block and cryptographic schematicdiagrams for credential base establishing in accordance with aspects andteachings of the present invention, with FIG. 16A related to theestablishing of a single base credential for a user and FIG. 16B relatedto establishment of a second credential base for the user.

FIGS. 17A and 17B are a combination block and cryptographic schematicdiagram for a pseudonym with credential showing in accordance withaspects and teachings of the present invention, with 17A related to thepseudonym itself and 17B related to the signature on the pseudonym.

FIGS. 18A and 18B are flowcharts for credential base and credentialpseudonym issuing in accordance with aspects and teachings of thepresent invention, with 18A related to the operation according to FIG.16A and FIG. 16B, as already described, and with FIG. 18B related toFIG. 17A and FIG. 17B as already described.

FIGS. 19A, 19B and 19C are combination block and cryptographic schematicdiagrams for payment initiations in accordance with aspects andteachings of the present invention, FIG. 19A related to the creation ofan account without initial funding, FIG. 19B related to the funding ofan account from value outside the accounts, and with FIG. 19C relatingto the transfer of value from an account to value held outside theaccounts.

FIGS. 20A, 20B and 20C, are flowcharts for establishing accounts andtransferring value between the accounts and external systems inaccordance with aspects and teachings of the present invention, withFIG. 20A related to the creation of an account without initial funding,FIG. 20B related to the funding of an account from value held by asubscriber outside the accounts, and with FIG. 20C relating to thetransfer of value from an account to value held by a subscriber outsidethe accounts.

FIGS. 21A, 21B and 21C are combination block and cryptographic schematicdiagrams for payment transfers between accounts in accordance withaspects and teachings of the present invention, with FIG. 21A related totransfer from one account to another, FIG. 21B related value funding twodifferent accounts, and FIG. 21C related to consolidation of change fromtwo accounts to a single account.

FIG. 22 are flowcharts for transferring value between accounts inaccordance with aspects and teachings of the present invention.

FIGS. 23A and 23B are combination block and cryptographic schematicdiagrams for protected communication from a first to a second subscriberin accordance with aspects and teachings of the present invention, withFIG. 23A related to message confidentiality and FIG. 23B related to bothmessage confidentiality and authentication of sender.

FIG. 24 is a combination block diagram and cryptographic schematic of anon-precomputation mix with message confidentiality in accordance withaspects and teachings of the present invention.

FIG. 25 is a combination block diagram and cryptographic schematic of aprecomputation portion of a mix with tail in accordance with aspects andteachings of the present invention.

FIG. 26 is a combination block diagram and cryptographic schematic of arealtime portion of a precomputation mix with tail in accordance withaspects and teachings of the present invention.

FIGS. 27A, 27B and 27C are combination block diagrams and flowcharts ofmixing with output delivery in accordance with aspects and teaching ofthe present invention, with FIG. 27A related to three-phase embodiments,FIG. 27B related to authentication of sender to recipient, and FIG. 27Crelated to secrecy of payload delivered to recipient.

FIGS. 28A, 28B and 28C are combination block diagram and cryptographicschematic diagrams of mixing with coordinated instances in accordancewith aspects and teaching of the present invention, with FIG. 28Arelated to multi-node mixing with pre-unpermuted and optionalpost-unpermuted phases, FIG. 28B related to multi-node mixing withcoordinated permutations and optional pre-unpermuted and optionalpos-unpermuted phases, and FIG. 28C related to multi-node mixing withcoordinated inverse permutations and optional pre-unpermuted andoptional post-unpermuted phases.

FIGS. 29A and 29B are combination block diagrams and flowcharts ofmixing with general coordinated instances in accordance with aspects andteachings of the present invention, with FIG. 29A related to embodimentsincluding those without pre-computation and FIG. 29B related to examplesincluding pre-computation.

FIGS. 30A and 30B are combination block diagrams and flowcharts ofmixing with specific coordinated instances in accordance with aspectsand teachings of the present invention, with FIG. 30A relating toembodiments with application of the same permutation and FIG. 30Brelating to examples including application of an inverse permutation.

FIG. 31 is a combination block and cryptographic schematic diagram formulticast in accordance with aspects and teachings of the presentinvention.

FIG. 32 is a combination block diagram and flowchart of multicast inaccordance with aspects and teachings of the present invention.

FIG. 33 is a combination block and cryptographic schematic diagram forhybrid encryption in accordance with aspects and teachings of thepresent invention.

FIG. 34 is a combination block diagram and flowchart of hybridencryption in accordance with aspects and teachings of the presentinvention related to the embodiment also described in FIG. 33.

FIG. 35 is a combination block and cryptographic schematic diagram forasynchronous sending of larger payloads in accordance with aspects andteachings of the present invention.

FIGS. 36A and 36B are combination block and cryptographic schematicdiagrams for anonymous selection of feeds in accordance with aspects andteachings of the present invention, with FIG. 36A related to therecipient establishing the choice of feeds and FIG. 36B related to therecipient polling the feeds.

FIGS. 37A and 37B are combination block diagrams and flowcharts oflow-bandwidth selection are shown in accordance with aspects andteachings of the present invention, with FIG. 37A related to aspectscommon to FIGS. 35 and 36 and FIG. 37B related to a server-sidearchitecture.

FIGS. 38A, 38B and 38C are combination block diagram and flowchart ofanonymous selected data and subsets of data and user computation inaccordance with aspects and teachings of the present invention, withFIG. 38A related to posting of data and forwarding of access to it andsubsequent downloading by the recipient and FIG. 38B related to theposting by a user of a set of feed identifiers and their subsequent usein receiving feeds and FIG. 38C related to the user device side of theembodiments described with reference to FIG. 37AB.

FIG. 39 is a combination block and cryptographic schematic diagram foradditive split mixing in accordance with aspects and teachings of thepresent invention.

FIGS. 40A 40B and 40C are combination block diagram and flowchart ofadditive split mixing in accordance with aspects and teachings of thepresent invention, with FIG. 40A related to the case shown on the leftof FIG. 39, with FIG. 40B and with FIG. 40C related to the input andoutput options already described with reference to the right side ofFIG. 39.

FIG. 41 provides a combination block and cryptographic schematic diagramfor pseudonymous sender authentication in accordance with aspects andteachings of the present invention.

FIG. 42 gives a combination flowchart and block diagram for pseudonymoussender authentication in accordance with aspects and teachings of thepresent invention.

Turning to FIGS. 43A and 43B are combination block and cryptographicschematic diagrams for hybrid sending in accordance with aspects andteachings of the present invention, with FIG. 43A related to thepreparing a hybrid sending channel and with FIG. 43A related to thesending of an encrypted payload through an established hybrid sendingchannel.

FIGS. 44A and 44B, finally, are combination block diagrams andflowcharts of hybrid sending in accordance with aspects and teachings ofthe present invention, with FIG. 44A related to preparing a hybridsending channel and FIG. 44B related to the sending of an encryptedpayload through an already established hybrid sending channel.

DETAILED DESCRIPTION

A description adequate to allow those of skill in the art to make anduse will now be provided but it will be understood that simplificationsand restrictions may be included for clarity but without any limitationwhatsoever.

Turning now to FIG. 1, a combination block diagram and cryptographicprotocol schematic of a mix without pre-computation is shown inaccordance with aspects of the teachings of the present invention. Theuser input indicated in the column on the left, the mix nodes andintermediate values in the middle, and the payload messages output inthe column on the right. The values are shown using a multiplicativegroup with exponentiation indicated by a carrot “{circumflex over ( )}”as will be understood.

The dotted rectangle indicates the mix hardware device extent. It mayalso be considered to be an example of the boundary of the mix network,such as in terms of a block diagram, with the inputs and outputs outsidethe boundary as already mentioned. The internal structure of the mixconfiguration is indicated as including an unpermuted section and apermuted section, as will be understood as an example. The input vectoris shown on the left and the output vector on the right, as labeled.Similar conventions will be used to some extent in subsequent diagrams,as will be appreciated.

The message content, c, is shown indexed by a natural number, chosen forclarity as if the first user is user number one, the second, two, and soforth; but of course it will be understood that in general the usersparticipating in a particular cascade may be whatever subset ofsubscribers and they may appear in whatever order, such as the order inwhich they send their input in. Thus, c(1) may be considered for clarityand concreteness to be as an example the message content, which issometimes also referred to as the “payload,” of the message of the firstuser to send a message in for this cascade instance.

The input items, making up the left column as mentioned, are each raisedto a power that is shown as the product of two applications of thefunction k. The first application includes the “x” as the secondargument; the second application of k includes “y” as the secondargument. The first parameter shown in both cases is the subscriberindex as already mentioned. Accordingly, k(1,x) is the key held as asecret in common between subscriber one and mix node x; and k(2,x) knownto subscriber two and mix node x; similarly, k(4,y) for example, is thatknown to the fourth subscriber and node y.

The processing by node x is indicated by the arrows passing through thebox labeled x. Thus, as will readily be appreciated, this node knows thekeys it has in common with the subscribers, who are identified in thisunpermuted phase, as indicated by the horizontal arrows, and the nodecancels these factors, such as by multiplying by the multiplicativeinverse of them, as will readily be understood. The node also appliesthe same key, x, to all the messages, as mentioned, thereby leaving themessages in a normalized form.

The processing by node y is similar, using the keys known to y.Accordingly, y raises the messages to the inverse power corresponding tothe keys in common with the respective users and also includes the powery known to it. This leaves the content, c(i), sent by the subscribersbut raised to both the x and the y power.

Next the vector of such messages is processed, in this example, by nodex, in the permuting phase. There are two operations performed by a nodeon the messages during this phase; permuting and decrypting.Accordingly, x chooses a permutation, ideally one that is hard forothers to predict, such as a random permutation, for instance chosenindependently and uniformly from all permutations of the number ofmessages used. The decrypting can be by raising the elements to thepower that is the inverse of the key x. These two operations can beperformed in whatever order with the same result.

The final operation of the permuting phase, in this example with twonodes, is the similar permuting and decrypting by the second node, aswill be seen. Of course, any number of nodes can be used in the mixcascade in general, as is known and will be readily understood isapplicable generally to all descriptions provided in the presentapplication.

The result output by the mix, shown as the column on the right asmentioned, is the message content items or payloads sent by thesubscribers, but in an order that represents the composition of thepermutations chosen by each successive node.

As an example, for further concreteness as may be appreciated, the firstinput item shown, in the upper left, c(1){circumflex over( )}k(1,x)k(1,y), represents the message content c(1) raised to a powerthat is the product of two exponents: k(1,x), the power common to theuser and node x, and k(1,y), the power common to the same user and nodey. Following this same message along, in the unpermuted phase, itappears in the first position of the intermediate vector between nodes xand y in the form: c(1){circumflex over ( )}k(1,y)x, showing that x hasremoved the common key and replaced it with the power x. Similarly, theoutput from y, the second intermediate vector, includes this message inthe form: c(1){circumflex over ( )}xy, where the common key between userone and y has been cancelled and the power y injected to normalize themessage. Following the message through processing by x, which asindicated includes the permutation that takes one into three, themessage can be seen in the third position in the output vector as of theform c(1){circumflex over ( )}y. And, similarly, following it to theoutput vector, through processing by y, it appears in the fifth positionas c(1).

Turning to FIG. 2, a combination block diagram and flowchart of a mixwithout pre-computation is shown in accordance with aspects and theteachings of the present invention. Initially, ideally secret keysbecome known to each node for each subscriber, such as by beingestablished for subscribers by nodes and/or with various levels ofcooperation by subscribers, as indicated by box 210. These were shown ask(i,j), where i is the user and j the node. Various means and methodsfor establishing keys are known in the art, as will be understood,including for instance physical exchange of key material, key agreementprotocols, public key systems, as mentioned more generally earlier.

The input received by the mix, as described in box 220, includesencryption, such as commutative encryption in the examples, thatincludes keys held in common by a subscriber and a node. The next stepshown 250 is the unpermuted phase, during which nodes know thesubscriber or subscriber index and normalize by canceling the commonkeys while introducing the node keys, as already described withreference to FIG. 1. Then, finally, the permuted phase 260, alsodetailed with reference to FIG. 1, where the nodes remove the round keysinstalled on the items in the previous phase, the unpermuted phase, andthe message payload emerges as output.

Turning now to FIG. 3, an exemplary combination block diagram andcryptographic schematic of a precomputation mix is shown in accordancewith aspects and the teachings of the present invention. The upperportion shows the precomputation and the lower portion the realtimeportion. The user input and the output messages are shown on the leftand right of the lower dotted rectangle, respectively, much as alreadydescribed with reference to FIG. 1. The values shown are in a groupdenoted multiplicatively, for clarity, as will be appreciated. Also, ahomomorphic encryption function, h, for instance over the same group, isused in the precomputation and then decrypted by the nodes, again in theexample for clarity.

The example shown uses two nodes, x and y, for clarity; however, use ofany number of nodes will readily be understood from the description, asalready mentioned more generally. The example performs theprecomputation in the forward directions, but other directions may beused, such as the reverse direction, as will be understood.

In the pre-computation, the first node x begins, by applying thehomomorphic encryption in the unpermuted precomputation phase, shown inthe upper left. Each of the five example unpermuted input what will becalled here “slots” receives a random group element, shown as r(i,x),where i ranges over the input slot indices, as will be seen.

The homomorphic function, h(i), allows for the accumulation of elementsby the group operation, in this case shown multiplicatively, as is wellknown. For instance, h(i)h(j) is equal to h(ij). The vector of randomvalues or keys known to x, r(i,x), is the vector of homomorphicintermediate values shown intermediate to x and y. The next valuesincluded in or what may be called here “injected into” the homomorphicencryptions are the keys from node y, shown as r(i,y). Thus, thehomomorphic encryption is of the component-wise product of the vector ofkeys from x and the vector of keys from y.

Next node x performs the first permutation of the permutedpre-computation. This rearrangement is indicated by the paths of therespective arrows within the rectangle labeled by x. The output of this,shown intermediate to the similar operation by y, is thus thepermutation of the homomorphic encryption vector input with thecomponent wise inclusion of a second vector of keys known to x, thes(i,x). The indices of the input vector can be seen to have beenre-arranged in accordance with the arrows and the new vector includedsubsequently with its unpermuted indices, for clarity.

Then node y performs similar transformations, as just described for x,but with permutation and keys known to y. The vector of products underthe homomorphic encryption is thus permuted again and has additionalfactor from y, the s(i,y).

The homomorphic encryption layer, shown as h( ), can as is well known beremoved by cooperation of the nodes who have shared the secret key ofthe homomorphic system. In the well-known El Gamal homomorphicencryption system (its additive group operation being shown heremultiplicatively for clarity), for example, the nodes cooperate tocompute a public power of the agreed generator, by each nodesuccessively applying its secret exponent. Then, for the correspondingdecryption of the homomorphic system, the nodes apply the inverse oftheir secret exponents successively to remove the encryption on eachelement of the vector. This is indicated by the vector passingunpermuted through the rectangles of each of the two nodes in the upperright corner. This computation or decryption operation, may, as will beappreciated, be conducted well in advance or, for instance, once therealtime phase completes successfully in some examples.

The realtime portion of the mixing is shown beginning with input itemssubmitted by subscribers, as indicated on the left of the lower portionof the figure. Instead of the exponentiation already described withreference to FIG. 1, the users include elements in the input message byapplying the group operation, which is shown multiplicatively forclarity. In an example El Gamal homomorphic system, however, thesubscribers would add their group elements modulo the public modulus toform their respective messages, which is believed a very efficientoperation.

The elements included by the subscribers are, again similar to thesystem already described with reference to FIG. 1, the keys they have incommon with the nodes and the message content they wish to send. Herethese three are shown as factors, multiplicatively, as mentioned.

These inputs to the realtime mix are shown then being processed by x inthis first part of the unpermuted phase. The vector that x injects intothe message vector at this point is the r(i,x) that were the firstelements include in the homomorphic unpermuted phase already described.Also, x removes or what may be called here “cancels,” such as byapplying the inverse group operation, the value of the respectivek(i,x), the keys in common with x and the subscriber i. Thus, the k(i,x)factors are replaced by r(i,x) factors. Again, as will be appreciatedhas been detailed with reference to FIG. 1, the indices of thesubscribers are shown as successive natural numbers, but need not havebeen known during the pre-computation nor need be related to the indicesof the keys r(i,x).

The next processing, by y, is similar, as would be processing by anynumber of successive nodes. The common key vector is divided out and thecorresponding r vector multiplied in (at least in the notation used, butthe group operation may actually be addition, as mentioned).

Next, the realtime permuted phase begins, in the example shown forclarity with the first node x. As with the corresponding processingalready described with regard to the pre-computation permuted phase, xpermutes the input vector with the same rearrangement as in thepre-computation and performs a component wise group operation with therandom vector, s(i,x). This leaves four factors in the intermediatevalue.

The operation performed by the next node, in this example y, is similar:the same permutation is applied to the input vector and the groupoperation is used to combine component-wise with the same random/keyvector used in the pre-computation, in this example s(i,y). Again, anynumber of nodes will readily be understood, two having been shown asmerely an example for clarity.

At this point the cancellation may be accomplished. (In othernon-limiting examples, it may be accomplished at other points; thispoint being believed advantageous and shown for clarity.) It will beappreciated that the output of the homomorphic decryption includes allthe factors of each message that remain, apart from the message content.Accordingly, forming the inverse in the group and combining by the groupoperation, shown as division in this multiplicative notion for clarity,leaves the message content in permuted order as the output vector.

As an example, for further concreteness as may be appreciated, the upperleft corner shows x producing an output vector with first componenth(r(1,x)) representing injection into the homomorphic system the keyr(1,x) for the first slot. Then when y injects r(1,y), the vectorcontains h(r(1,x)r(1,y)) as first component. Of course, as will readilybe understood, this can also be written as h(r(1,x)r(1,y)), because ofthe homomorphic property of the cryptosystem as already described, butthe form shown is believed more readily understood.

Next the component is permuted as shown by x to the third positionh(r(1,x)r(1,y)s(3,x)), and the additional key s(3,x) is injected. Once ypermutes this to the sixth position (the permutations here being thesame as those of FIG. 1 for clarity but without loss of generality) thisitem has the form h(r(1,x)r(1,y)s(3,x)s(5,y)). Now the homomorphicdecryption is shown as involving successive operations by x and by y,for concreteness, without limitation. The result of the decryption then,for the sixth element, is shown below the line, in the “denominator,”suggesting that the group operation is applied after the inverse in thegroup has been computed, as will be understood. It is of the formr(1,x)r(1,y)s(3,x)s(5,y), where the factors were included from left toright for clarity. The numerator shows the same factors, apart from themessage c(1), but in the reverse order, as they were included from rightto left. Accordingly, the result is the payload message c(1) appearingin position six of the output vector, as indicated.

The realtime processing that leads up to this output is shown beginningagain in the upper left of the realtime phase as the first component orslot of user input k(1,x)k(1,y)c(1), again with the index being assignedto match the slot number here for clarity in description and notation,but without any limitation whatsoever. (It will be understood that anassignment of senders to slots that is randomized in a way outside thecontrol of less than all the nodes may be advantageous.) This is theproduct of the input message and the keys in common between this userand the two respective nodes. The output vector from x contains thefirst element as r(1,x)k(1,y)c(1), where the factor k(1,x) has beenreplaced on the left by r(1,x). Similarly, the processing by y yieldsr(1,x)r(1,y)c(1) in the first unpermuted component, with k(1,y) shownreplaced in the same position for clarity by r(1,y). Now the permutationby x takes this component to the third position (same permutation as inthe pre-computation) and includes s(3,x) as a factor to yields(3,x)r(1,x)r(1,y)c(1). And finally, processing by y takes this to thefifth position and includes s(5,y) on the left, givings(5,y)s(3,x)r(1,x)r(1,y)c(1). So, the fifth position of the outputvector is the output of message c(1).

Turning to FIG. 4, a flowchart is shown of exemplary pre-computationmixing in accordance with aspects of the teachings of the presentinvention. The realtime portion, similar to that already described withreference to FIG. 2 is shown on the right and the pre-computationportion is shown on the left.

The first step 450 of the pre-computation, as already described withreference to the example of FIG. 3, is the creation of a multi-partyencrypted computation system, such as a homomorphic encryption system.In the example, mentioned for clarity and concreteness but without anylimitation, this is accomplished by the development of a public keywhose private key is divided among the nodes, such as by the raising tothe respective secret powers of the nodes an agreed generator in adiscrete log group, as per the El Gamal cryptosystem.

The next step 460 is the unpermuted and then the permuted phases of thepre-computation using the shared key to, in the example, develop thehomomorphic encryption or otherwise of the cancellation vector, still inencrypted form, such as already described with reference to FIG. 3.

In step 470 the combining and/or decryption to obtain the cancellationinformation, shown in the example of the homomorphism encryption, isbefore being applied to the messages in order to cancel the various keysincluded by the nodes that hide the messages during processing. Thedecrypted cancellation vector can be included at various points in theprocessing, such as already mentioned. For instance, including it at theend, as in the example described with reference to FIG. 3, correspondsto the forward order of the pre-computation and is believedadvantageous. However, other orders for the pre-computation and/or otherlocations to insert the cancellation vector, are anticipated.

As already described with reference to FIG. 2, the nodes develop commonkeys with subscribers pairwise, at least in some examples, as shown inbox 410. The nodes receive 420 input provided by subscribers to the mixthat include aspects related to the common keys as well as the messagecontent.

The realtime processing of the input begins with the non-permuting phase430, as already detailed in the example of FIG. 3, during which thesubscriber common keys are replaced by other keys of the nodes, such asin the example r keys. Before or after this processing, in some examplesthe pre-computation output may enter. However, in the example describedwith forward pre-computation, the pre-computation enters at the end ofthe realtime phase, as shown after box 440.

Finally, box 440 is the realtime permuting processing of the inputmessages. Each node processes, in the example, by permuting andinjecting key material, with the example s key injection. When thecancellation vector is included, these remaining keys are cancelled,leaving the message content as output in the example.

Turning now to FIG. 5, a combination block diagram and cryptographicschematic of a pipelined unpermuted phase is described in accordancewith aspects and the teachings of the present invention. Portions of theinput vector are shown processed first by different nodes and then theportions are interchanged so that each portion is ultimately processedby each node. Such arrangements are referred to here as “pipelining.”

It will again be appreciated that a network topology other than asequence of hops may result in lower end-to-end delay, for instance, andthereby may be advantageous. It will also be understood that some usersmay be “closer” in terms of latency to different “entrance” nodes.

With reference to the example of the figure, the first three subscribersare shown supplying their input directly to node x, whereas the last twoare shown supplying to node y. After processing by these first-linenodes, the messages are then routed through the other nodes so that allthe processing as described, for instance with reference to FIG. 3, maybe accomplished. The result of the this realtime pipeline is shownlimited to the unpermuted phase and delivering its output to thepermuted phase in parallel.

Although the example is shown with reference to the pre-computationexample, it may be applied to other examples, such as those describedwith reference to FIG. 1 or FIG. 2.

Turning now to FIG. 6, an example broadcast unpermuted phase is shown incombination block and cryptographic schematic in accordance with aspectsand the teachings of the present invention. The user input to the mix isshown on the left, as already described with reference to FIG. 3. Thisinput is copied or broadcast to more than one node.

In the example two nodes are shown for clarity; however, broadcast toany number of nodes will readily be understood. It will be appreciatedthat a network topology of a star rather than a sequence of hops withthe same number of nodes may result in lower end-to-end delay, forinstance, and thereby may be advantageous.

Each node receiving the broadcast includes the key information, in theexample r(i,x) or r(i,y), and removes the subscriber common keys itknows. However, and as will be appreciated, the common key isadvantageously in effect removed also from the other copies when theyare re-combined as shown. Thus, accordingly in such examples, the commonkeys enter in the inverse under the group operation with a multiplicityequal the number of copies, one for each node. For instance, asindicated in the example, the common key divided out by the node appearswith multiplicity two, but one copy is shown in the numerator, so thenet result is that the inverse appears with multiplicity one; but thisis believed what is wanted to cancel the appearance of the factor whenrecombined as shown.

When the copies are recombined using the group operation, as shown, theresult is that the common keys are cancelled and the key matter, r( ) inthe example, included by the respective nodes remains. Thus, as will beappreciated, this result is suitable for processing by the realtimepermuted phase, shown as a dotted rectangle labeled x,y and includingthe composition of the permutations used in other examples here.

Very concretely, as may be appreciated for clarity, the third componentoutput by x, k(3,x)k(3,y)c(3)r(3,x)/k(3,x){circumflex over ( )}n, can bewritten includes k(3,x)k(3,y)c(3)/k(3,x) and so when it is multiplied bythe third component of the output vector of y, k(3,x)c(3)r(3,y)/k(3,y),the k( )'s drop out and the result is the desired r(3,x)r(3,y)c(3), thesame as shown as the third component of the input to the realtimepermuted phase in FIG. 3 already described.

Turning now to FIG. 7AB, flowcharts of pipelined and star unpermutedphases are shown in accordance with aspects of the teachings of thepresent invention. FIG. 7A relates to the pipelined configurationalready described with reference to FIG. 5. FIG. 7B relates to the starconfiguration described already with reference to FIG. 6.

Referring specifically to FIG. 7A, first step 710 shows processing of aportion of the input by a first node. A second node processes 720 aseparate portion of the input, at about the same time as the first nodeprocesses the first portion. Then, the at least two nodes each process730 the portions already processed by the other node. In some examplessuch pipelining may relate to unpermuted phases of a pre-computed mix,such as already described in detail with reference to FIG. 5. However,it will also be readily appreciated, and in view of the more generaldescription earlier, that this figure may be applicable to a pipeliningof a mix without pre-computation.

Referring specifically now to FIG. 7B, first step 750 is shown copyingdata into at least two copies related to the input to the unpermutedphase, whether direct input or, as will be understood, such as inexamples where pipelining and star configurations are combined. Thennodes include 770 keys in copies related to the node. Finally, theprocessed copies are combined 790 using in the example the appropriategroup operation and provided to the permuted phase for furtherprocessing. Steps 770 and 790 cooperate so that the common keys areremoved.

It will readily be appreciated that variations include combinations ofthe approaches described with reference to FIGS. 7A and 7B, and thecorresponding FIG. 5 and FIG. 6. For instance, as just one non-limitingexample, some pipelining may allow entrance nodes to be located nearsenders, but some broadcast by those nodes may reduce overall delaycompared to pure pipelining.

Turning now to FIG. 8AB, combination block diagrams and cryptographicschematics of exemplary authentication from users to nodes are shown inaccordance with aspects and teachings of the present invention. It willbe understood as mentioned more generally that authentication by morethan one node may be advantageous compared to authentication by a singlenode; for instance, in terms of credibility with various userpopulations who may have varying trust in authentication by differentnodes. Authenticators aimed at individual nodes are shown in examplesrelated to the examples already detailed without and then withpre-computation. In some examples, if a node's test of an authenticatorconcludes that the authenticator is invalid, that node should followprotocol and signal other nodes by raising an error condition and theinput is ideally rejected and/or regarded as inauthentic.

Referring specifically now to FIG. 8A, an example from FIG. 1 is shownwith subscriber identification and explicit authentication provided toeach node by each subscriber. The subscriber corresponding to the firstinput, even though the index is shown as one, as already described withreference to FIG. 1 and FIG. 3, is shown as #68 for the first input, and#76 for the second, and so on. In addition to the explicit indication ofthe subscriber identity along with the input, authentication informationis shown explicitly.

In the example, each node receives separate authentication informationfrom each subscriber. In some instances, such authentication may forexample include cryptographic authenticators, such as for instancecode-words, so-called “MAC”s, “digital signatures,” or whatever type ofauthenticator. These authenticators are shown using the notation:a(<sender>, <node>). For instance, the third line shows sender withidentity #88 providing authenticator a(88,x) to node x. In the examplethe authenticators are removed by a node that is to check them, thoughthis may be optional and may or may not actually result in an efficiencyimprovement and forwarding all authenticators to all nodes may beadvantageous, such as because of simplicity or robustness in the face ofchanges in processing.

In some examples authenticators may be a single MAC based on the commonkey between the node and the sender; the authenticator may even be smallcompared to conventional prior art practice, as the authenticationeffect is believe to be cumulative across nodes in some examples. Forinstance, if there are twenty nodes and each authenticator is merely asingle eight-bit byte, the combined effect may be considered to beequivalent to a one-hundred-sixty-bit authenticator by those who trustall nodes and an eighty-bit authenticator by those who trust whateverhalf of the nodes.

Referring now to FIG. 8B, an example from FIG. 3 is shown forconcreteness with subscriber identification and explicit authenticationprovided to each node. The subscriber corresponding to the third input,#88, provides the authenticator a(88,x) to node x and a(88,y) to y.

Turning to FIG. 9, a flowchart is shown of exemplary authenticationaspects in accordance with aspects and teachings of the presentinvention. The authentication examples already described with referenceto FIG. 8A and FIG. 8B are described in terms of more general combinedflow with some or all nodes participating.

The nodes establish common secrets with subscribers at least for otherpurposes as described here, such as with reference to FIG. 1 and FIG. 3,for unlinkability. These same keys additionally, and/or optionally otherkeys, may be used for authentication; however, the common keys will betaken here as used for authentication without limitation or loss ofgenerality. As mentioned already with reference to FIG. 8, suchauthentication can be by one or more nodes. It need not be applieduniformly for all users. It may be applied adaptively, such as changingusers and nodes based on past experience. Public key authentication ofsubscriber submissions is also anticipated; however, it is believed thatsymmetric encryption and small authenticator size may be advantageous interms at least of efficiency. In some cases making using the same keyfor different functions is known to inhibit the release of the key forone function as it also enables other functions; though multiplepurposes for a single key may be frowned upon for cleanliness in securedesigns.

Referring now specifically to the figure, step 910 is the establishingof the keying information at least by the nodes that is known to pairsmade up of a user and a node. Step 940 includes nodes receivingauthenticators and checking the validity of the authenticators using thecommon keys corresponding to the sending subscribers. Then in step 970nodes may optionally signal other entities, such as for instance othernodes, that a particular authentication has failed to check. In someexamples, if authentication fails a message may simply not be forwarded,be replaced by some other information, or not be passed forward. As willbe understood, not shown for clarity, is signaling that authenticationis successful.

FIG. 10 through FIG. 27 to be described are believed to be transactionoverlays that can apply to or be adapted to apply to a wide range ofuntraceable sending schemes, including mixes, and specifically alsoincluding the mixes described here with reference to FIG. 1 and FIG. 3.

Turning now to FIG. 10AB, combination block and cryptographic schematicdiagrams are shown for basic single and multiple message block sendingin accordance with aspects and teachings of the present invention. FIG.10A is the sending of a single block message; FIG. 10B depicts sendingof an example of two messages that are linked at output to form a singleconcatenated message.

The diagrams show two example phases of mixing, unpermuted and permuted.They apply for instance to the embodiments described with reference toFIGS. 3 and 4 to those of FIG. 1 and FIG. 2, as well as to a wide rangeof mixing. A multiplicative notation may be used for clarity, as alreadydescribed, but without limitation. The particular order and to someextent groupings are examples, as will be understood.

As used elsewhere here, such as with reference to FIG. 12, FIG. 14, FIG.16, FIG. 17, FIG. 19, FIG. 21, and FIG. 23 the rectangles in the centershow two aspects of the novel mixing disclosed here, unpermuted andpermuted phases, respectively; the messages travel straight through theunpermuted phase and are shown with an example interchange in thepermuted phase. In some cases dotted lines illustrate other traffic notdescribed in detail for clarity. Example snapshots of message form areprovided, such as for the input on the left and the output on the rightand in some examples in the intermediate phases. The hash sign “#”followed by an integer is intended to denote the identity of a user orsubscriber. Elements in coma-delimited lists that begin with a capital“T” are here called “tags,” data items identifying a type of data.

Referring now more specifically to FIG. 10A, a basic untraceablemessaging system is shown. Two example senders, #33 and #48 are shownusing the basic message tag “T1,” as mentioned. What is sometimesreferred to here and elsewhere as the “payload” of their messages ismessage content c(1) and c(2), respectively. The tag is included in theinput, in a way intended to indicate that it may be visible to the mixnodes and when visible in the output may be shown there as well. The“p(c(1))” notation is intended to indicate that the message content c(1)is encrypted for decryption by the mix nodes as the payload carried bythe message and is in some examples cleartext or the like on output.Each message may be thought of as being treated separately in thisexample.

Referring to FIG. 10B, however, messages may be grouped so that theresulting payloads can be combined, such as by concatenation, intolarger message outputs. The tag for this type of message is shown as“T1*” in order to suggest that it may be a candidate to replace tag “T1”throughout a system to offer larger payloads and accordingly the otherexamples shown using “T1” may be taken to be “T1*” tags as an alternateembodiment.

In the example illustrated, for clarity and concreteness, two inputs areshown from the same user, #16, one with a payload of c(1 a) and theother with payload c(1 b). The two inputs from the same user are mixedto different and essentially randomized positions in the output vector;however, because of the tag “T1*” the first field of each is treated aswhat will here be called a “marker,” shown as “z(1)” and “z′(1),”allowing the pair to be recognized and the two outputs to be groupedtogether, such as by the concatenation “c(1 a) c(1 b),” as will beunderstood. In some examples the outputs may be sorted and these fieldsmay be in the higher-order positions and such pairs or larger sequencesmay appear as adjacent, particularly if they differ only in their lowerorder bits as sequence bits and are chosen randomly and of sufficientlength to reduce the possibility of collisions, as will be understood.Thus, markers may be said here to “match” if they appear to relate tothe same message at least with high likelihood.

Turning now to FIG. 11, a flowchart is shown for multiple message blocksending in accordance with aspects and teachings of the presentinvention. The steps correspond to the operation according to FIG. 10Balready described.

Referring to step 1110, a subscriber forms a first message input to themix that includes a marker that is at least unlikely to be chosen byanother user instance, such as by choosing the marker at random. Asecond message with a related marker is also formed 1130 by a user. Themessages are treated as inputs to a mix, in some examples for the samebatch, and they are mixed 1150. The resulting messages in the output ofthe mix are linked 1170 by the related markers, such as by appearingadjacent in sort order as mentioned earlier. Finally, the linked messageoutputs are assembled and/or treated together 1190.

Turning now to FIGS. 12AB, combination block and cryptographic schematicdiagrams are shown for untraceable return addresses in accordance withaspects and teachings of aspects of the present invention. FIG. 12Aillustrates the establishing of an untraceable return address; FIG. 12Bdepicts the sending of a message using such an untraceable returnaddress by a sender directing the message to the creator of theuntraceable return address, even though the identity of the creator ofthe untraceable return address is unknown to the sender.

What are here called “untraceable return addresses,” such as thoseproposed by the present applicant in the original mix publicationsmentioned earlier, are known in mixing systems. The present exampleillustrates how they can be achieved in a novel aspect of the presentnovel mixing. An example use of such a technique is where the sender ofa request wishes to remain anonymous to the recipient of the request,but still wishes to receive the reply.

Referring specifically first to FIG. 12A, in what may be referred tohere as “establishing” the untraceable return address, the user #98 inthe example provides an input with the tag “T2.” What will be calledhere a “marker” is the first component of the payload. In the exampleshown, the marker w is formed as the product of images under a one wayfunction f of two keys, w(1) and w(2), and the address of the user #98.These keys are shown as each separately encrypted, one as the thirdcomponent of the payload and the other as the fourth: the encryption ofw(1) for node X using the public key of node X is denoted e(x,w(1)); theencryption of w(2) for Y similarly as e(v,w(2)).

In the output, the same tag appears again to denote the type of mix,with w in the clear, identifying this output instance so that in someexamples the decrypted keys can be linked to it and used with it as afirst payload as will be described with reference to FIG. 12B.

Referring now to FIG. 12B, a subscriber #33 wishes to send the messagec(1) to the subscriber who has established the untraceable returnaddress. The untraceable return address is supplied in some way bysubscriber #98 to subscriber #33. In some examples, the untraceablereturn address may be sent, for instance, by being published or as apayload in a T1 message as already described. In whatever way theuntraceable return address is sent, in the example it consists ofw=f(w(1))f(w(2))#98 and ac(1), where a=f′(w(1))f′(w(2)).

When the tag “T3” appears in the input, the mixes know to use thesecrets that were encrypted under their respective public keys from thecorresponding instance of FIG. 12A, identified by the w that alsoappears in the input. Each mix applies the one-way function f to thesecret w( ) separately received in the instance of FIG. 12A and dividesthe result out of the third input component, w. The result, afterpassing through all mixes, is that the delivery address #98 appears asthe second output component. Treatment of the fourth input component bythe mixes is similar, but instead of f a different one-way function, f′,is used, believed advantageous in the example for instance in terms ofkeeping #33 from discovering the address #98. Accordingly, the cleartextpayload c(1) is shown as the third component of the output.

It is anticipated that payload content may be encrypted by the secondsubscriber, such as using keys also supplied by the first subscriber. Itis further anticipated that a single first establishing instance can beused for multiple sendings.

Turning now to FIG. 13, a return address sending flowchart is shown inaccordance with aspects and teachings of the present invention. Thesteps correspond to the operation according to FIG. 12A and FIG. 12B, asalready described.

The first user sends the return address through a mix 1320, to hide thecorrespondence between the user and the address, establishing theuntraceable return address. Then the first user provides 1340 a seconduser with the address. Next, the second subscriber who has obtained thereturn address from the first subscriber uses it 1360 to form a mixinput that includes both the return address and an actual messagecontent. Once this input from the second user is mixed 1380 therecipient address and payload appear in the output.

It will be appreciated that among the advantageous properties achievedby the examples shown are believed to be: that the second user cannotlearn the identity of the first user; that the first user does not needto anticipate the identity of the second user in forming the untraceablereturn address; that no persistent public keys are maintained by thenodes across the various batches; and that no public key operations areperformed in sending, mixing or delivering the message from the secondsubscriber.

Turning to FIGS. 14AB, combination block and cryptographic schematicdiagrams are shown for limitation of multi-sending in accordance withaspects and teachings of the present invention. FIG. 14A is thelimitation to a single sending of a particular type per user; and FIG.14B shows the indication being determined in a way that at least theuser cannot readily guess what it will be or control what it will be.The same tag type “T4,” optionally with variations, is used for bothkinds of messages and variations with any number of messages, withrevealed and or partially or fully hidden count anticipated.

Referring more specifically to the example of FIG. 14A, the input fromuser #45 is shown with tag “T4.1” as mentioned, a count of one, a valueu here called a “designator” in an encrypted form and a p( ) encryptedpayload message c(1) as described already elsewhere. The first node, xin the example, removes the base common key value, shown as k°(45,x),which is fixed for this pair of user and node, such as for instancebeing computed by each as unique one-way function of a common seed. Nodex also checks that this designator has not been used previously by #45,in accordance with the count of one, as indicated by the “?=?” equalitytest notation used here. Then the second node removes the base commonkey value, k°(45,y) from #45, and also similarly checks that thisdesignator has not been used previously by #45.

In another novel aspect, with more general applicability, but shown onlyhere for clarity, instead of factors r(x) and r(y) being included inwhat is sometimes called the “base,” that is the value being raised towhatever power, factors denoted v(x) and v(y) are shown in the exponentof a modular arithmetic system. Accordingly, these factors are removedby raising to powers corresponding to their inverses during the permutedphase, as will be understood. The result is the cleartext designator u,already described and to be described further, being output.

Not indicated for clarity as elsewhere here, as will be appreciated, arethe additional factors or encryptions inserted during the non-permutingphase, as already described, such as with reference to FIG. 1 and toFIG. 3.

It will be appreciated that the user/subscribed being able to choose thedesignator while keeping confidential which designator which senderchooses but ensuring that no user/subscriber can repeat a designator,allows the designator to be chosen by the user/subscriber, for instance,as the name of an election or online forum or other association of datawhere such assurances are advantageous. For instance, voting aparticular contest is typically to be limited to one vote per user andposting on a forum or group or whatever associated public or limiteddistribution data under a pseudonym in some circumstances isadvantageously done while establishing that the user posts there underno other pseudonyms.

Technically, as will readily be appreciated by those of skill in theart, in some embodiments the users should not be able to choose the uvalues freely, but rather in a way that limits what can be known aboutthe structure of these values in the number system. Such issues are wellknown in signature schemes and are solved, for instance, by includingpadding structure requirements in the number or requiring that thenumber be an image under other cryptographic functions and the like. Avariety of ways are known and anticipated to allow the users to choosethe values to encode the election or forum or the like without givingtoo much control over the structure of such numbers. As a concreteexample, u can be defined as the image under a hash function of a uniqueencoding of text defining the actual election contest or forum or thelike.

It will also, however, be appreciated related to FIG. 14A that abelieved advantageous inventive aspect is that by varying the numbershown as one in the figure, a different limit can be put on the numberof instances, and the subscriber sending the limited number of messagescan remain anonymous among the subscribers sending limited messages forwhatever designations.

Referring now to FIG. 14B, an example is provided of a messagedesignator that is believed hard for the sender to predict. It ismoreover, in this example, what may be called here “repeatable acrossmultiple senders”: put differently, if two independent senders use thesame input parameter, the same indication should result. Differenceswith the examples described with reference to FIGS. 14AB include thatthe count is not shown as checked and the exponents applied by the nodesare unknown to the users.

In one example application, users who wish to be in contact with eachother only in the case that there is a mutual such interest can sendmessages with both user identities (e.g., concatenated in a fixed ordersuch as lexicographic). If multiple items are posted as a result,replies can be generated. In some examples, replies can be byuntraceable return addresses, such as those described with reference toFIGS. 12AB and FIG. 13, contained in the payloads. In other non-limitingexamples, return indications, such as those described with reference toFIG. 28ABC, FIG. 29AB and FIG. 30AB, can inform senders of a match.

Turning now to FIG. 15AB, flowcharts are given for limitation ofmulti-sending and other encrypted payloads in accordance with aspectsand teachings of the present invention. The steps of FIG. 15A correspondto the operation according to FIG. 14A and FIG. 14B, as alreadydescribed; those of FIG. 15B relate to those of FIG. 14C.

Referring now particularly to FIG. 15A, step 1510 is the subscriberforming the input to the mix, including by encrypting the designator ina way that yields the same encrypted value for that user and thatdesignator, such as that described already with reference to FIG. 14A.The nodes check 1420 the encrypted designator and the count of thenumber of times if any it has been used previously; if this check fails,in some examples at least, the nodes abort the processing of themessage.

It will be understood that the nodes may each “see” a differentencryption of the designator, as they remove and/or apply encryptionsuccessively, as already mentioned or they may see the input data.Further processing 1530 in a permuted phase by the mix nodes furtherdecrypts the designator. The output of the mix includes 1540 thedecrypted designator and a count or the like if applicable.

Referring to FIG. 15B, step 1550 is the user encrypting a designator sothat it will repeat across users, as has already been mentioned withreference to FIG. 14C. The message may include a message type indicatorand other payloads, as has been mentioned. Step 1560 shows the mix nodesencrypting the designator, successively, as it travels through the mix.The keys used for this encryption, need not be public, but forrepeatability across users would typically be retained and usedrepeatedly, as will be understood. Also, as will be understood, ifpublic keys are available related to these private keys, verification ofthe process may be provided for. Finally, referring to step 1570, theencrypted designators are output along with whatever types and optionalpayload(s), as mentioned.

Turning to FIGS. 16AB, combination block and cryptographic schematicdiagrams are shown for credential base establishing in accordance withaspects and teachings of the present invention. FIG. 16A is theestablishing of a single base credential for a user; FIG. 16B showsestablishment of a second credential base for the user. The same tagtype “T5” is used for both kinds of messages and variations with anynumber of bases, with revealed and or partially or fully hidden countare also anticipated. It will be appreciated, however, that a believedadvantageous inventive aspect is that the base credentials are notlinked to the actual credentials, as will be described further withreference to FIGS. 17A and 17B.

Referring more specifically now to the example of FIG. 16A, the inputfrom user #75 is shown in this example with tag “T5” as mentioned, and acount of one. The actual base number can be chosen by the nodes invarious ways; an example provided is as a so-called “one-way” function fof the user number and the count. This value, however, is encrypted bythe nodes successively, in some examples using special keys for thispurpose, shown here as x′″ and y′″. It is believed that these keys neednot be made public, but are used here in some sense to keep users frombeing able to create these values themselves. The encrypted image underf becomes the pseudonym base in the output, as shown, and can berecognized by the subscriber or simply returned to the subscriber, asthere is no permuting phase in this example for clarity. The resultingcredential base is shown as b and will be referred to again withreference to FIGS. 17A and 17B.

Referring to FIG. 16B, the input from user #75 is again shown in thisexample with tag “T5” as mentioned and a count of two, which is checkedfor by the nodes, only two of which are shown here for clarity aselsewhere and as will be understood. The other difference with FIG. 16Aalready described is that the output base is shown as b′. Any number ofsuch additional instances may be allowed in some examples. When it isdesired that they should be distinguished, different keys can be used bythe nodes for the distinguishable instances.

Turning to FIGS. 17A and 17B, a combination block and cryptographicschematic diagram is given for a pseudonym with credential showing inaccordance with aspects and teachings of the present invention. A singlepseudonym with a single credential is shown for a user; however,additional payload instances may advantageously show credentials onthem, as will be mentioned, but these additional credentials are notshown for clarity.

Referring specifically now to the figure, subscriber #75 uses tag “T6”to indicate transmission of what will be understood by those of skill inthe art may be referred to as a “credential on a pseudonym.” This ismade up of the two payloads shown for clarity: the first is thepseudonym itself; the second is the credential “power” or “signature” onthe pseudonym.

At each unpermuted step, the nodes apply the same function f used tocreate the base pseudonym in processing the first component, as alreadydescribed with reference to FIG. 16. What they apply the function to,however, are images under k′. Each such k′ in the example can can alsobe computed by the user. Accordingly, the user is believed to know thepower of the public generator g that is combined multiplicatively withthe image under f.

During each permuted step, the nodes apply the x′″ and so forth to thefirst payload component and the second payload is decrypted using x andy, as in already described examples as will be understood. What isbelieved accordingly to be provided to the recipient is a pair ofvalues, the second being the secret q power of the first.

The value q in the example is the secret exponent of the organization orentity issuing the credential, as will be understood by those of skillin the art. This issuer in the example makes public a power of analready public number, in the example shown, the x′″ and y′″ power ofthe public generator g. Thus, user #75 can form c, as already mentioned,and then apply c to this public value to obtain the second componentshown transmitted.

The recipient organization would of course typically wish to verify thatthe two components received are in fact related by the exponent of theissuer, q. One way this can be accomplished, as will readily be apparentto those of skill in the art, is through an interactive proof with theissuer. In such a proof, the pair can even be hidden from the issuer, byso-called “blinding,” as will also be understood.

It is believed that in typical example applications the recipient maywish to what is sometimes referred to as “link” the various pseudonymsthat arrive from the same user. One example way to accomplish this, aswill be readily understood, is to include a further component in thetransmissions and for it to be some form of authenticator of the user,such as a pass-phrase or signature or the like. In other believedadvantageous examples, as will also be appreciated, a credential may beshown that is unique to the combination of issuer and user. Accordingly,for instance, the recipient chooses a unique exponent key for the userand issues the user a credential with it and then expects to see thatpower on the same base as already described for the other credentialreceived in the transmission.

Turning now to FIG. 18AB, flowcharts are provided for credential baseand credential pseudonym issuing in accordance with aspects andteachings of the present invention. The steps of 18A correspond to theoperation according to FIG. 16A and FIG. 16B, as already described;while those of FIG. 17A and FIG. 17B, correspond to those of FIG. 18B,as already described.

Referring to FIG. 18A, the user begins by requesting 1810 a credentialbase using a particular message type for this purpose. Then the nodescheck 1820 a count related to the type of base requested, to ensure thatonly the allowed number of instances of the base type are issued to theparticular user. Next the nodes form 1830 a base in a way that the usercannot know the relation to another base, such as being able to expresseach as a different public-key encryption of a common value. In someexamples, this is by choosing the bases as images under a so-called“one-way” or other cryptographic function without known structurerelated to the signature technique to be employed for the credentialsystem. Finally, nodes mix 1840 the base as they apply encryptions so asto make the base in practice unlinkable to the requesting subscriber.

Referring to FIG. 18B, the user begins by requesting 1860 a credentialpseudonym, using a designated message type for the request, so that themessage receives corresponding processing by the nodes. The nodes thenencrypt 1870 the submission by applying cryptographic transformationsknown to but at least not fully controllable by the user. This isbelieved to allow the user to transform signatures on one pseudonym ofthe same base onto the other pseudonyms of the same base, as in knowncredential mechanisms. Next the nodes mix 1880 the pseudonym from theprevious step, applying encryptions that hide the association betweenthe user and the output pseudonym. In the examples shown, but withoutany limitation, this is accomplished in a way that matches what was donein establishing the pseudonym base, so that the relationship between thebase and the pseudonyms is known to the user, in the example in terms ofan exponent.

Turning to FIGS. 19A-C, combination block and cryptographic schematicdiagrams are shown for payment initiations in accordance with aspectsand teachings of the present invention. FIG. 19A is the creation of anaccount without initial funding, an optional facility; FIG. 1B showsfunding an account from value held by a subscriber outside the accountsdescribed here, which may include creating the account if it is notalready extant. And FIG. 19C depicts the transfer of value from anaccount to value held by a subscriber outside the accounts described.

Referring more specifically to FIG. 19A, using a format and notationsimilar to that already described earlier, a tag of “T7 a” is used toindicate this type of transaction, again merely for concreteness in theexamples. The subscriber #91 sends the message of type “T1” on the sendside, so that it can advantageously, it is believed, be hidden in amongother messages of this type, many of which may for instance be for otherpurposes including non-transactional purposes. The payload, as shown,contains what will be called an “embedded” tag type, in this case “T7a,” to indicate on the output side only that the message requests thecreation of an account. The other component of the payload shown is theimage under a one-way function f of a random value chosen by the user,q. In some examples, control over an account is demonstrated by theshowing of such a pre-image q; so, for instance, to move value from theaccount, at a later time once it has value in it by techniques to bedescribed, the presentation of q in a message will authorize thattransfer.

It will be understood by those of skill in the cryptographic transactionart that types of authenticators other than pre-images under a publicone-way function may be employed for such authentication purposes.Examples include, public key digital signatures, undeniable signatures,hash function trees or chains, etc. It is believed that a one-wayfunction may be more economical than a signature and adequate under someassumptions about the system; these functions will be used here in thedescription for concreteness and clarity but without any limitationwhatsoever. In some examples, not shown for clarity, more than one suchimage or pre-image under the one-way function may fit in a singlepayload, and so more than one underlying operation can be performed permessage. Also, as will be appreciated the choice of one-way function mayencode denomination and/or currency.

An administrator of the accounts on the output side of the sendingsystem is anticipated. This may be a entity separate from the nodes,related to the nodes, and/or with whatever multiplicity. It isanticipated that the account administrator, considered a single separateentity for clarity, maintains a list of accounts. Each account consistsof at least some of: an identifier, an owner authentication, a balance adenomination/currency, and/or an indication of status such as open orclosed. In some examples the identifier is the image under the one-wayfunction (or the public key) related to the values used in establishingthe account; the pre-image (or signatures) are then the authenticatorsused to move value from the account, whether to other accounts or to thesubscribers, both as will be described. What will be referred to here asa “denomination” is the amount of value in the account. It is well knownthat a fixed binary denomination scheme, such as 2, 4, 8, and so forthunits of value is efficient and can be enhance untraceability. Otherdenomination schemes are anticipated as are accounts with arbitraryvalue possibilities, such as integer number of cents, millicents, oreven real number values.

The account(s) on the input side of the system, as will be understood,may be part of any known or existing type of financial or value system,such as bank accounts, digital currencies, or certificates of ownership.Moreover, as will readily be appreciated, whatever multiplicity andvariety of such accounts may be provided. The accounts may beadministered and/or owned and/or controlled by whatever entity orentities, such as the administrator of the output side, alreadymentioned, one or more nodes separately or jointly, and/or otherentities for this purpose.

Referring now more specifically to FIG. 19B, a deposit transaction isshown. The user #36 deposits a denomination d worth of value fromoutside the system, such as from a bank account, credit card, or cash,to an account within the system that is is identified as f(q) in theexample. Thus, this transaction can create an account and associate avalue d with it and fund it with the value d. In the example, each nodehas the option to test, validate, or otherwise verify whether the valuewas transferred in, during the unpermuted phase as indicated by the termused here “value” and the “?=?” notation used here of a test. The outputpayload is believed essentially unlinkable to the user, since theidentifier f(q) is hidden as the payload within p( ). If a user were tochoose an f(q) that is already in use and already funded, some exceptionmay occur. In one example, the user may be able to move the extrafunding out of the account by showing q or for instance q′, such thatf(q′)=q.

In some examples it may be required that the account exist before it canbe funded and thus the transaction already described with reference toFIG. 19A may be used for this purpose. In other examples, however, it isbelieved adequate that the account would be created by the deposittransaction described with reference to FIG. 19B and/or by a transfer aswill be described with reference to FIGS. 21ABC and FIGS. 22ABC.

Referring now to FIG. 19C, a transaction is shown that is believed ableto allow what may be called the “owner” of an account to withdraw orremove the value from the account by in effect transferring that valueoutside of the system of accounts in favor of the subscriber. Theexample presented here may be regarded as a so-called “optimistic” one,in that it will be assumed that the account exists and is funded;however, in the case this turns out not to be true, provisions may bemade to trace back to the user and undo or prevent the transaction fromconsummating. Such what will be called “exception” handling is indicatedin the figure as being part of the permuting phase. This is to suggestthat the nodes keep information sufficient to allow such exceptionaltransactions to be traced backwards (such as the permutations related tothe transactions of this type in a batch); however, such tracing backmay only be needed more or less instantly, as whether the account existsand is funded can be checked immediately when the payload arrives, atleast in some examples.

In some applications of payments, withdrawals may be made directly by atleast certain entities, such as shops, without the privacy of theprotocol example described, as will be understood.

Also, in some applications the exception provision may be replaced bythe use of a non-permuting tail technique and certified transactionsthat will be described with reference to FIG. 23AB, and that will alsobe mentioned with reference to FIG. 21. A relative advantage of the tailis that the exception possibility and lack of forward secrecy it impliesmay not be needed; a relative advantage of the exception, however, isbelieved greater efficiency.

Turning now to FIG. 20A-C, flowcharts are provided for establishingaccounts and transferring value between the accounts and externalsystems in accordance with aspects and teachings of the presentinvention. The steps correspond to the operation according to FIG. 19A,FIG. 19B, and FIG. 19C, respectively, as already described.

Referring to FIG. 20A, although the user or subscriber action need notbe considered a part of the novel aspects, as elsewhere here, as will beunderstood, they are shown explicitly for clarity. Accordingly, the usercreates 2005 an authenticator and account identifier, such as bychoosing a mainly random value and using it to generate a pair of keyssuch as a public key and a private key or, as in the example, apre-image and an identifying image under a function believed one-way.Next the user requests 2010 creation of the account, by including anappropriate tag and the identifier as the payload of a message. Therequest can, it is believed, advantageously be included in among othermessages being sent. The request can optionally include a denomination,as already mentioned.

The nodes process 2015 the request, such as by considering it a payloadand passing it through the un-permuting and permuting phases alreadydescribed, in order to hide the particular use requesting the particularaccount. Once the message appears in the mix output, the account iscreated 2020 with the corresponding identifier and optionally with therequested denomination. Any collision can result in no account beingcreated and/or an exception, as already described with reference to FIG.19C; however, it is believed that such provisions need not be made inpractical systems.

Referring to FIG. 20B, payment by a user into an account include, forclarity, but without limitation, as mentioned, a request 2030 by a userin a designated message type. The user supplies 2035 value, or receivedfrom an external system or whatever other type of value is accepted. Thenodes can check 2040 that the value was received relative to therequest. The nodes decrypt 2045 the account designation, which travelsas the payload in the example, during the mixing of the message. Nodesmark 2050 the output corresponding to the designated message type, suchas corresponding to the amount deposited and include the accountidentifier. The account is then marked 2055 as funded.

Referring to FIG. 20C, in a payment to a user from an account,alternatively a withdrawal from the accounts, for clarity, but withoutlimitation, as mentioned, may be considered to include a request 2070 bya user in a designated message type. The request received 2075 includesa user identifier, an amount, and a payload specifying the accountauthenticator and if not recoverable from the authenticator, the accountidentifier. The payload decryption 2080 by the mix reveals theauthentication and denomination in the output of the mix in thecorresponding designated message type. If the corresponding value isavailable in the corresponding account, and it is requested only thisonce in this batch, and the authentication is valid, then the value isremoved from the account and the transaction completes successfully2085. If, however, one or more conditions are not met, then an exceptionindication 2090 is sent back through the mix to reveal the input-siderequest that is then cancelled.

Turning to FIGS. 21A-C, combination block and cryptographic schematicdiagrams are shown for payment transfers between accounts in accordancewith aspects and teachings of the present invention. FIG. 21A is thetransfer from one account to another; FIG. 21B shows a changetransaction in which value in one account split into value funding twodifferent accounts; and FIG. 21C depicts a consolidation of change inwhich value from two accounts is moved to a single account. It will beunderstood, however, that many other combinations and variations arereadily conceived by those of skill in the payments art and these aremerely examples based on an exemplary binary denomination scheme usedhere for clarity and to provide what is believed a relatively simple yetsufficient set of transaction types.

Referring specifically now to FIG. 21A, the transfer of value betweentwo accounts is shown. The user #54 in the example requests the transferand includes an authenticator (from which the identifier is assumedreadily computable in the example) for the source account and anidentifier for the receiving account. The payload is shown containingthe tag “T7 d” and the information about the two accounts.

As will be understood, various conditions that may not hold can beassumed and/or dealt with in various ways. For instance, (a) the sourceaccount may have no value; (b) the destination account may have adifferent denomination; (c) the destination account may already befunded; and/or (d) the destination account may not exist. Variousstrategies for dealing with these error situations may readily beconceived. For instance: non-existent accounts may be created (d);denominations of accounts adjusted (b); or the whole transactioncancelled (a) or (c). An exception could be generated, such as alreadydescribed with reference to FIG. 19B. It is believed that, forefficiency it may be assumed that the user has checked on thesepotential errors and avoids them, particularly if destruction of valueis the system rule in such cases and so the cost of providing for anexception condition may be avoided in practice.

Referring specifically next to FIG. 21B, the transfer of value from oneaccount into two is shown. The user #99 in the example requests thesplit, such as part of a change making, and includes an authenticator(from which the identifier is assumed readily computable in the example)for the source account and identifiers for the receiving accounts. Thepayload is shown containing the tag “T7 e” and the information about thethree accounts and authenticator for the source account. As will readilybe appreciated, the various example conditions already described withreference to FIG. 21A have close analogies here and there may beadditional issues raised by the addition of a third account. However,the same comments generally apply, as will readily be understood.

Referring finally now to FIG. 21C, the consolidation of value from twoaccounts into one is shown. The user #16 in the example requests thechange transaction of “merging of two coins into one,” and includes thetwo authenticators (from which the identifiers are assumed readilycomputable in the example) for the source accounts and an identifier forthe consolidation destination account. The payload is shown containingthe tag “T7 f” and the information about the three accounts andauthenticators for the source accounts. Again, the various exampleconditions already described with reference to FIG. 21A and FIG. 21Bhave close analogies here; however, the same comments again generallyapply, as will readily be understood.

As just one example variation, it will be understood that the initiatorof a transfer or change transaction may wish to be notified in case itsucceeds or in other examples if it fails. One way to accomplish this isusing the non permuting tail techniques that will be described withreference to FIG. 23AB, as already mentioned with reference to FIG. 19C.An example of where this may be useful is to a subscriber that sendsidentifiers of a number of unfunded coins as a kind of invoice and thenwishes to transfer those to other coins and learn that the transferswere successful in order to determine that the invoice was paid.

Turning to FIG. 22, flowcharts are provided for transferring valuebetween accounts in accordance with aspects and teachings of the presentinvention. The steps correspond to the operation according to FIG. 21A,FIG. 21B, and FIG. 21C, as already described.

The transactions are initiated by receipt of a request, or depending onthe perspective, the sending of a request, as mentioned. The requestincludes 2220 designation of at least one source account and at leastone destination account. Authentication is supplied 2240 for the atleast one source account. The payload mixed includes 2240 identifiersfor the at least one destination account. The step, accomplished afterthe mixing, of checking 2260 the authentication for the at least onesource account, which as mentioned earlier may be assumed to allow readydetermination of the corresponding account identifiers(s). Finally,value is transferred 2280 from the at least one source account to the atleast one destination account, assuming the conditions for the transfer,such as those described with reference to FIG. 21A, FIG. 21B and FIG.21C are satisfied. Various such transactions can, as mentioned, becombined in a single message.

Turning to FIGS. 23AB, combination block and cryptographic schematicdiagrams are shown for protected communication from a first to a secondsubscriber in accordance with aspects and teachings of the presentinvention. FIG. 23A shows an example with message confidentiality; FIG.23B gives an example with both message confidentiality andauthentication of sender. The diagrams are similar to those alreadydescribed, such as with reference to FIG. 16, FIG. 17, FIG. 19, and FIG.21; however, additional processing is shown. (Somewhat more detailedexamples, as will be appreciated, related more to the embodiment of FIG.23A will also be described with reference to FIG. 24 withoutprecomputation and with precomputation in FIG. 25 and FIG. 26.)

Referring specifically now to FIG. 23A, a subscriber shown in theexample as “#40” provides input to the mix in a “T8” tag type message.The payload includes an embedded type tag “T8,” specific to this type ofmessage, a recipient identifier, “#21” in this example, and a payloadc(1), shown in the example multiplied by or what may here be called“protected” by two group elements combined by a group operation g(x) andg(y).

Processing recovers the payload, in a manner roughly similar for exampleto that for tag type T1 already described with reference to FIG. 10A.

An additional unpermuted processing by nodes, what may here be called a“tail,” is shown. The tail decrypts the received payload in stages, bythe corresponding nodes successively removing the correspondingprotection, as will be understood; however each also includes the k(,)respective encryption for the recipient already identified as #21. Thus,the message content can be delivered to the recipient, identified in theexample output in cleartext, in a form that the recipient can decrypt,by re-constructing the k(,), and thereby recover the message contentc(1).

Referring now to the exemplary embodiment of FIG. 23B, a difference withFIG. 23A already described is that the tag type is “T9” for clarity andthere are two separate payloads. The first payload is decrypted by theunpermuted and permuted phase as already described above, to yield #21as the output; the second payload, however, may be considered to becreated by the nodes from the sender identity “#40,” in the example, aswill be appreciated. It is protected, as shown, by the factors d(x) andd(y), injected by the respective nodes. (In some examples, as will beunderstood, these factors may be included in a portion of thepre-computation that follows the permutation portion but is still underhomomorphic encryption; when the homomorphic decryption is removed,these factors are thus in the corresponding messages of the unpermutedpost phase.)

In the tail processing shown, which is non-permuting, each successivenode replaces its d( ) by a corresponding k(,) for the recipient #21.This is delivered to the recipient who is able to decrypt the k(,)factors and thereby recover the “#40” that identifies the sender.

As just one example to illustrate uses for a tail that includes thesender identity the option for a “certified” transfer between accountshas been mentioned earlier with reference to FIG. 21. Even withoutpayload, the receipt of such a message could indicate that one or moretransfers, whether or not they include combining or splitting coins,completed successfully; in other examples, such a message might be sentwithout identifying the original sender in case transfers do notsucceed. (The distinction believed significant as the party who wishesto verify that the payment were successful could be defrauded if anotherparty could falsify such a message indicating that they were successful;whereas, a party that only expects to be notified in case the paymentsfail could only be defrauded by deletion of such a message.)

As already mentioned with reference to FIG. 14, a variation generallywould allow the user to have a pseudonym identify postings that are madepublic in the output, such that the user cannot choose the pseudonym,but it can be used repeatably by that user. As just one example, therevealing of the user identity in an intermediate stage as describedhere with reference to FIG. 23 is believed also optionally modified toallow the user identity to appear in an encrypted form, such that theencryption remains the same across instances.

Turning now to FIG. 24, an exemplary combination block diagram andcryptographic schematic of a non-precomputation mix with messageconfidentiality is shown in accordance with aspects and teachings of thepresent invention. The subscriber sending the message includes anintended recipient as well as a payload, as separate components of atransmission.

Relative to the example already described with reference to FIG. 1, itwill be appreciated that an additional payload input is shown introducedby the user that includes an encryption of identification of theintended recipient. For instance, in the first input by user “#1” (forclarity also in input slot one, even thought the particular slots neednot be related to the user identities, as already mentioned), therecipient is designated as subscriber “#6,” and this is hidden by theapplications of k(1,x) and k(1,y) and then by x and y. The payload c(1)is protected, in this example, first by k′(,) and then by x′ and y′ andthen by x″ and y″ and then by k″(,).

As the messages travel through the stages of the three phases, the pairconsisting of these two payloads travels together, as can be seen. Inthe first phase, which is unpermuted, the k(,) and k′(,) are exchangedfor xy and x′y′, respectively. Then, in the permuting phase, the x,y areremoved but the x′,y′ are replaced by x″,y″. This allows the next phase,the unpermuted tail, to deliver to the intended recipients using thecleartext recipient identifier revealed by the decrypted first payload;but with message content, c( ), that remains protected and at this stageby the application of k″(,) with the recipient identity as the firstparameter.

Turning now to FIG. 25, an exemplary combination block diagram andcryptographic schematic of a precomputation portion of a mix with tailis shown in accordance with aspects and teachings of the presentinvention. (The corresponding realtime portion will be described indetail with reference to FIG. 26.)

Relative to the example already described with reference to the upperportion of FIG. 3, it will be appreciated that an additional randomfactor v(,), similar to r(,) and s(,), is shown introduced in thenon-permuted phase.

Turning now to FIG. 26, an exemplary combination block diagram andcryptographic schematic of a realtime portion of a precomputation mixwith tail is shown in accordance with aspects and teachings of thepresent invention. (The corresponding precomputation portion has alreadybeen described in detail with reference to FIG. 25.)

Relative to the example already described with reference to the lowerportion of FIG. 3, it will be appreciated that an additional randomfactor v(,), similar to r(,) and s(,), is shown introduced in thenon-permuted phase. Also introduced in the non-permuting phase are thek′ common keys with the designated recipients. For example, in the firstrow the designated recipient revealed by the output of the permutingphase, but for the component not shown for clarity that carried therecipient identity, is the identifier #6. (Again, the choices for theseidentifiers corresponding to the slots is for convenience and clarity,as will be appreciated, but does not limit the dynamic choice ofidentities to slots that can be made in realtime.)

The results of the homomorphic decryption, from FIG. 25, similar tothose from the upper half of FIG. 3, are divided out as shown and cancelthe v, r, and s factors. Thus, the recipient subscriber identified (notshown for clarity, but 6 through 0 from top to bottom in the example) isable to decrypt the content using the common keys.

Turning to FIG. 27ABC, combination block diagrams and flowcharts ofmixing with output delivery are shown in accordance with aspects andteaching of the present invention. FIG. 27A relates to three-phaseembodiments; FIG. 27B to examples including authentication of sender torecipient; and FIG. 27C to examples including secrecy of payloaddelivered to recipient.

Referring specifically now to FIG. 27A, a first step 2705 is shown asoptionally performing a pre-computation to obtain keying information, ashas been described already earlier here. Next step 2710 shows developingcommon secrets between nodes and subscribers, as also describedelsewhere here. These first two steps may be an whatever order orparallel as will be understood.

The next three steps are the unpermuted, permuted, and unpermutedprocessing, such as for example described with reference to FIG. 23,FIG. 24, FIG. 25, and FIG. 26. The first unpermuted phase 2720 removescommon keying related to the subscribers providing the input, whileproviding protection through injection of other keying aspects. Thepermuted phase 2725 permutes the items while modifying the keying, alsoas already described. The second unpermuted phase 2730 removes keyingand also includes common keying with recipients.

Referring to FIG. 27B, three phases are shown for providingauthentication of sender, such as already described with reference toFIG. 23B. A first unpermuted phase 2740 the common keying withsubscribers is replaced by protection including of the sender address,which may not be identified as a payload item explicitly. A permutingphase 2745 modifies keying to hide the permutation. Then a secondnon-permuting phase 2750 removes sender address protection whilesubstituting common keying for the intended recipient, such as describedalready with reference to FIG. 23B.

Referring finally now to FIG. 27C, three phases are shown for providingconfidentiality of message content delivered, such as already describedwith reference to FIG. 23A and FIG. 23B. A first unpermuted phase 2760replaces common keying with subscribers by protection. A permuting phase2765 modifies keying to hide the permutation. Then a secondnon-permuting phase 2770 removes sender address protection whilesubstituting common keying for the intended recipient, such as describedalready with reference to FIG. 23A.

Turning to FIG. 28ABC, combination block diagram and cryptographicschematic diagrams of mixing with coordinated instances are shown inaccordance with aspects and teaching of the present invention. FIG. 28Arelates to multi-node mixing with pre-unpermuted and optionalpost-unpermuted phases; FIG. 28B relates to multi-node mixing withcoordinated permutations and optional pre-unpermuted and optionalpos-unpermuted phases; and FIG. 28C relates to multi-node mixing withcoordinated inverse permutations and optional pre-unpermuted andoptional post-unpermuted phases.

Referring more particularly to FIG. 28A, three nodes are shownidentified, x, y, and z; however, the ellipsis explicitly indicates, aswill be readily understood and appreciated, that any number of nodes maybe used in the cascade structure shown. The multiplicity of nodes in theparticular order is indicated by the vertical dotted lines for thepermuted phase; whereas, for the unpermuted and optional unpermutedphases also shown, as will be understood, the order may not be the sameor the processing even linear, such as has been described with referenceto FIG. 5, FIG. 6, and FIGS. 7AB. These considerations are also believedapplicable to FIGS. 28B-C, to be described further.

The permutations realized by the respective nodes, x, y, and z, areshown as p(x), p(y), and p(z), respectively. The nodes use these in theoptional pre-computation and in the processing, as already described.

Referring more particularly now to FIG. 28B, the same permutations,p(x), p(y), and p(z), are shown performed by the same nodes, x, y, andz, and in the same order. The pre-unpermuted phase and thepost-unpermuted phase may each separately be considered optional in suchan embodiment. To the extent used, however, the values r, s, and t, fromFIG. 28A are shown replaced by the values r′, s′, and t′, respectively.Thus, it is believed that an instance from FIG. 28A and one from FIG.28B will process messages with the same composition of permutations. Forinstance, examples such as described with reference to FIG. 23B, thatinclude multiple payloads traveling together through a mix could each berealized by coordinated instances with the same permutation. In someexamples, not shown for clarity, also a short confirmation ofacknowledgement may be generated through such a mix, such as to confirmthat an acknowledgement has been received, as will be described, or toprovided a delayed confirmation of sending.

Referring more particularly to FIG. 28C, the inverse of the samepermutations, p(x), p(y), and p(z), are shown performed by the samenodes, x, y, and z, and in the reverse order of nodes. The inversepermutations are indicated by the bar over the name of the respectivenode: x, y, and z. The values protecting the permuted and optionalunpermuted phases are shown with double primes, r″, s″, and t″, as theyare believed advantageously distinct from those already described withreference to FIG. 28B using single primes.

The pre-unpermuted phase and the post-unpermuted phase may again eachseparately be considered optional in such an embodiment. Some exampleuses include for confirmation of transactions, such as those alreadydescribed with reference to FIG. 19ABC, FIG. 20ABC, FIG. 21ABC, and FIG.22. In particular, the exception condition already described withreference to FIG. 19C would be advantageously realized using thetechniques of the present figure, as tracing would be avoided eventhough certain transactions are cancelled. Other non-limiting exampleuses anticipated include so-called “delivery” notification of short textmessages and acknowledgements of receipt/acceptance in posting postingmessages or credentials.

Turning to FIG. 29AB, combination block diagrams and flowcharts ofmixing with general coordinated instances are shown in accordance withaspects and teachings of the present invention. FIG. 29A relates toembodiments including those without pre-computation; FIG. 29B relates toexamples including pre-computation.

Referring more particularly to FIG. 29A, box 2910 is the application ofa first permutation by a set of nodes in processing a first batch ofinput items. Step 2915 shows the application of a second permutationthat is related to the first permutation and the processing using thatsecond permutation of a second batch. Third and further batches are alsoanticipated. The actual processing of messages is for clarity shown inseparate boxes in this example; box 2920 is the application of the firstprocessing to first messages making up a first batch of messages; box2925 is the step of second processing of second messages making up asecond batch of messages.

Referring more particularly now to FIG. 29B, box 2950 is the applicationof a first permutation by a set of nodes in a pre-computation for afirst batch of input items. Step 2955 shows the application of a secondpermutation by a set of nodes for at least a second batch of itemsrelated to the delivery of the items output by the first processing.Third and further batches are also anticipated. Box 2960 is theapplication of the first processing using the first permutation to firstmessages making up a first batch of messages; box 2965 is the step ofsecond processing using the second permutation of items related to thedelivery of the items of the first processing.

Turning now to FIG. 30AB, combination block diagrams and flowcharts ofmixing with specific coordinated instances are shown in accordance withaspects and teachings of the present invention. FIG. 30A relates toembodiments with application of the same permutation; FIG. 30B relatesto examples including application of an inverse permutation. The figureis believed applicable whether or not there is precomputation.

Referring to FIG. 30A, the same permutation is applied to at least twobatches, with a first application shown in box 3050 and the second shownin box 3055. Then box 3020 and box 3025 show the processing of messagesin batches with the permutation, first in one batch 3020 and then inanother example 3025.

Referring finally to FIG. 30B, a first permutation is applied in a firstorder 3050 in the processing of a first batch of items, where the itemsin the example are from multiple senders, such as one item per sender.The messages are accordingly delivered 3055 to the intended respectivedestinations. Next the nodes cooperate in an ordering that is thereverse of that used in the first steps and the nodes apply permutationsthat are inverses of those that they applied in the first step. Thenodes apply 3060 these transformations in processing at least a secondbatch. The processing returns 3065 to at least a portion of the sendersof messages from step 3050 at least indications as the second batch thatare related to respective messages and/or destinations.

Turning to FIG. 31, a combination block and cryptographic schematicdiagram is provided for multicast in accordance with aspects andteachings of the present invention. The upper portion of the figurerelates to the sending of a single initial transmission by theoriginating subscriber; the lower portion of the figure relates to theforwarding on by the nodes of a single branch of the in generalmulti-way branching of the of copy instances of the single initialtransmission content payload.

Referring more specifically to the figure, two payloads are shown on theL.H.S. of the upper portion, making up the main portion of initialtransmission already mentioned. The first payload contains an embeddedtag, T10.2, that will label the components on the R.H.S. of this initialmix.

The two values following the tag each correspond to a respectivedestination for a copy of the multicast second payload. The h′ operatoris intended to indicate that a so-called hash or other compression ofthe full untraceable return address, as already described with referenceto FIGS. 12AB, may advantageously not be included at least in someexamples, since it is believed sufficient to identify the particularuntraceable return address already sent in an earlier protocol instance,such as an instance of FIG. 12A that has been stored for later access bythe nodes. The a(#98) style notation is intended to indicate an instanceof w related to the protocol of FIG. 12A corresponding to user #98, aswill be understood; similarly, a(#33) corresponds to a separate instanceof the untraceable return address establishing protocol, as alreadydescribed with reference to FIG. 12A.

The output of the upper portion, on the R.H.S., indicates the copyinginto instances, each to be delivered using a corresponding untraceablereturn address. It will be appreciated that the to values remain inplace and will be replaced by each respective node during the unpermutedphase of the lower portion LHS.

In the example shown, the particular untraceable return address instancedepicted for clarity is, arbitrarily chosen for the illustration, theone related to user #98. The full w, in FIG. 12A notation, shown asa(#98), as mentioned, is copied in as the first component; the secondcomponent has the t( ) values and the original transmission actualsecond payload c(1), the content being multicast as mentioned. Theprocessing through the mix is roughly as already described withreference to FIG. 12B. The result is that the message content c(1) isdelivered to user #98; however, not shown for clarity, such delivery itis believed would typically include protection of message content, suchas, for example, by the techniques already described with reference toFIG. 23A.

Turning now to FIG. 32, a combination block diagram and flowchart ofmulticast is shown in accordance with aspects and teachings of thepresent invention. The content sent by the originating sender isassociated with corresponding untraceable return addresses, as alreadydescribed with reference to FIG. 32.

Referring more particularly to the figure, box 3220 is the sending, bythe originating sender, of at least one message that includes both somekind of indication of the untraceable return addresses and some contentto be copied to the corresponding recipients. Next, box 3240 shows thatthe mixing disassociates or unlinks the untraceable return addressesfrom the sender. This step is optional but believed desirable. For onething, it may hide the number of copies sent; for another, it may hidethe repeated use of a set of untraceable return addresses.

The next step in processing by the mix nodes is shown in box 3260 asincluding copying the content, typically still in protected form, suchas already described with reference to FIG. 31. The final step shown, inbox 3280, is the mix nodes providing or delivering the content accordingto each corresponding untraceable return address.

Turning to FIG. 33, a combination block and cryptographic schematicdiagram is provided for hybrid encryption in accordance with aspects andteachings of the present invention. The example shown includes a singlesender of a potentially large payload c(2) that is encrypted withso-called “symmetric” or “conventional” cryptography, using a so-called“stream cipher” for clarity in the example, but which can readily beextended to whatever block or other cryptographic modes, as will readilybe understood.

The sender, user #77 in the example, chooses a key e, ideally in a waythat is hard or infeasible for others to guess, as is well known. Thesender then forms the transmission shown on the left hand side,including the tag T20 for this type of message. The next component isthe public generator, g, raised to this key power, g{circumflex over( )}e, encrypted for node x, with a single shared key k(x,1) in thisexample of this transaction type. Because of the large message streamcipher of this figure, the stream cipher encryption of c(2), is shownabove the box; the short arrow between the unpermuted and permuted phaseis intended to suggest this first stream encryption directly above it.The stream cipher is denoted by the plus symbol “+” for clarity, as willreadily be understood, as by any suitable operation, such as forinstance the often used exclusive-OR.

The penultimate component on the left has the addressee identifier aspayload, p(#55). The final component contains as payload two exemplaryalternate forms of keying material: the first is simply the secretexponent e itself; the other example option is a vector of the actualkeys used to successively encrypt c(2), as will be explained further.The former is believed faster for the sender to compute but more timeconsuming for the recipient; the latter faster for the recipient butmore time consuming for the sender. These last two components travelthrough the unpermuted and permuted and final unpermuted phases much aswith output delivery, as already explained such as with reference toFIG. 27A.

The first node, x, receives the data from the sender and transforms itand forwards the result on to the second node. More particularly, thethird from last component already described is decrypted by the firstnode x, after which x applies the example secret exponent x to it anduses the result as input to m that yields a value with the same size asc(2) that can be combined with c(2) as an additional stream ciphersequence. This transformation is indicated by the short arrow at theinterface between the first and second halves of the permuted phase andrelates to the result of the transformation shown above the box, asmentioned. The curly braces “{ }” are used to indicate that thesequantities are ideally encrypted by keys unique to each adjacent pair ofnodes in sequence. The node x further transforms the third from lastcomponent by raising to a further secret power shown as x′ beforetransferring to the next node in sequence, y. This is believed to allowy to produce the next key stream but to keep y from being able tore-produce the key stream used by x.

The second node, y, receives the data from its predecessor and forwardson to its successor essentially as any subsequent node in the sequencewould, as already described for x. This is also indicated by theellipsis in the figure. For one thing the third from last component isencrypted, in this case using key y, and this is used to generate a keysequence to further stream encrypt the c(2) payload. For another, thethird from last component is further encrypted by using y′ before beingsent on, as already mentioned.

Once the messages are delivered to the recipient, user #55 in theexample, the final component reveals the keying material to user #55 soit can recover c(2). In the first example option, more particularly, thevalue e is received. In this case, #55 can apply f to e to recover thefirst key stream and raise the first public value g{circumflex over( )}x (shown above the stream encrypted values) to the e power in orderto obtain the seed for the second key stream and then raise the secondpublic value to the e power to get the seed for the next stream.Removing the streams, such as by exclusive-OR as is well known, themessage content c(2) is obtained by #55. In the second example option,the seeds for the various streams are simply computed by #77 instead of#55 and formed into the vector n(i) for #55 to use to recover c(2).

Turning now to FIG. 34, a combination block diagram and flowchart ofhybrid encryption is shown in accordance with aspects and teachings ofthe present invention. The process steps relate to the descriptionalready provided for FIG. 33.

Referring more particularly to the figure, box 3420 is the creation ofthe key or keys by the sending subscriber. Then box 3440 shows theencryption of the content by the user with at least a part of the keymatter; also, the sender transforms the seed so that it will not bereadily computable by the first node.

Each node in sequence performs at least the encryption of the messageportion of the mixing cascade, as described in box 3460. One operationrelated to this is to transform the seed received from the previousstage to produce the seed used for the encryption at this stage. Anotheroperation, which may be optional but believed desirable, is to hide thevalue used for the encryption at this stage in what is forwarded on tothe next node.

Referring finally to box 3480, after the cascade has successivelyencrypted the message, the recipient subscriber receives the seed fromthe send via the mix, as already described earlier, and uses it tore-construct the seeds and corresponding streams and to remove thesefrom the message in order to recover the cleartext message.

Turning to FIG. 35, a combination block and cryptographic schematicdiagram is provided for asynchronous sending of larger payloads inaccordance with aspects and teachings of the present invention. Inaddition to the mixing shown as a second phase at the bottom of thefigure, there is a first posting phase and a third asynchronous recoveryphase. The inventive techniques in part relate to known so-called “multiserver private information retrieval,” a subject about which there isbelieved considerable academic literature.

Referring more specifically to the figure, the left side shows the firstor posting phase (as indicated by the numeral one reversed from theblack disc). The user, in the example shown as #18, has what is denotedfor clarity as a, an item of data, such as for example but withoutlimitation chosen from the group including for instance a photograph, asound clip, a video clip, a scan, a software program, a digitaldocument, any or all in whatever format. The user “uploads” the dataitem, such as by sending it to a designated server or service over acomputer network, but in an encrypted form. The example form ofencryption shown for clarity uses an encryption function, e, with afirst argument z that is a unique key of the user and the secondargument that is the data item to encrypt, as will readily beunderstood.

Obtained by the sending user #18, in the example, is an identifier froma conveniently dense space of such identifiers, such as a sequencenumber or the like. For clarity and so as to fit on the page, a very fewdata items are shown in the illustration; typically, there might be fromthousands to millions of such items. The identifier for the particularexample uploaded data item is shown as the number three.

Referring now to the second phase, mixing with pre- and post-unpermutedphases is shown, such as has already been described, for instance withreference to FIG. 28. Thus user #18 in the example sends a message touser #55 through the mix that includes the identifier and the key z, asalready mentioned.

(As an illustrative example, for clarity but without any limitation,user #55 may, for instance, have received the message including sometext, t, and an indication that there is a photo that can be obtained.The message may, not shown explicitly for clarity, contain and/orreference some kind of compact indication of the nature of the photo,such as an icon or low-res image. It may also typically be referred toin the text portion of the message. In any event, user #55 may notimmediately try to obtain the photo, but rather may do so after somedelay, such as after reading the text message.)

Referring to the third and final phase, where user #55 seeks to obtainthe particular data item without revealing which of the data items thatuser has selected and will receive. To accomplish this, in outline, theuser first forms a request, sends it to the servers x and y, two insteadof a larger number being shown for clarity as will be appreciated, whooperate according to it, providing a response to the user shown, andthen the user is able to recover the encrypted data item and decrypt itusing the already mentioned received key z. The request includes anindication of the user identity #55.

The request also includes what may be called here a “sent selectionstring,” shown as a literal binary string in square brackets, which isencrypted using a key shared with a selected one of the servers, in theexample x. The sent selection string in the example illustrated is sevenbits long, one bit for each of the identifiers in thisas-already-mentioned small example for clarity. Each non-selected serverrecreates a corresponding selection string using its respective sharedkey with the identified user. Thus, the non-selected server y generatesthe seven bit string in the example, “0100100,” from the shared key inan agreed manner replicable by the user, as shown: applying k(y,55,i)for the ith bit of the string.

The user, as will be appreciated, also computes the exact same generatedselection strings and then uses these to determine the sent selectionstring. This is done so that the bitwise-sum of all the selectionstrings, one per server, is all zero except that there is a one in theposition corresponding to the identifier of the desired data, in thisexample the number three received. Put differently, the selectionstrings sum bitwise to the zero vector apart from the single set bit inthe position of the desired data item.

As indicated in the figure, each bit of a selection vector is combinedwith the entire corresponding data item, which is shown for clarityusing the symbol “┐.” This in the example group, without limitation forclarity, flips every bit of the data item if the selection bit is oneand does not flip any of the bits if the selection bit for that item iszero; put differently, all the unselected items are forced to appearwith even parity and the selected item with odd parity. Thus, everyitem—except the single one desired by the user—cancels, since each setbit of it enters the exclusive-or sum an even number of times; however,the third data item in the example is the result, since each of its bitpositions with a set bit results in a set bit in the component-wise sumof all the vectors. Those data items that are inverted are shown with acheck symbol, “ü,” and are to be flipped; those without the check arenot to be flipped. It will be appreciated that only the data item q(3)has an odd number of checks/flips, and so it is the only item notcancelled and appears in the sum in its entirety unmodified.

The bitwise exclusive-or sum, the group used without limitation in theexample, is formed by the servers; however, included in the vector eachserver contributes is an ideally fresh key sequence generated from theshared key, as indicated by the k′ function. So user #55 also computesthese key sequences and bitwise exclusive-or's them into the receivedvector, so that the user-generated and node generated pairs cancel eachother, and the user recovers the encrypted data item, e(z,a), which theuser then decrypts with the key z as already described as received.

Turning to FIG. 36AB, a combination block and cryptographic schematicdiagram is provided for anonymous selection of feeds in accordance withaspects and teachings of the present invention. There are commonelements with the embodiment described already with reference to FIG.35. One difference is that the sender does not provide the data to therecipient, but rather the recipient chooses a number of senders, such asposters or publishers of data, whose data “feed” the recipient wishes to“follow” with the recipient revealing to neither the senders nor thesystem which senders the user wishes to receive feeds from. FIG. 36Ashows the recipient establishing the choice of feeds; FIG. 36B shows therecipient polling the feeds using the established choice of feeds.

Referring specifically now to FIG. 36A, user #22 in the example wishesto receive feeds from senders s(1) through s(z), and so sends this listto, for instance a public place or specific servers or the like, withthe tag <feeds>. The system replies with an identifier, this time fivein the example. The messaging described elsewhere here, such as withreference to FIG. 28, can be used for this. The intention is that thesystem will now collect together the latest from the senders on the listand maintain this collection under the identifier five; however, whichuser requested this collection be made available is believed hidden insome embodiments even from collusion of a proper subset of nodes.

Referring now to FIG. 36B, the same user in the example who hasestablished the list of senders that was assigned position five in FIG.36A above, now wishes to download over a public network the latestcollection of postings associated with that list.

The underlying technique for this is similar to that already describedwith reference to the third phase of FIG. 35. The user forms thegenerated selection strings and computes the selection string to send toa node, y in this example. The bit positions to be cancelled, all butposition five in this example, are given even parity, as alreadydescribed in detail with reference to FIG. 35; those with odd parity aremarked by a check and a check in the sent selection string indicatesthat the parity is to be flipped by y responsive to the sent selectionstring. The resulting bitwise sum computed by the servers is shown againencrypted with a fresh portion of the shared key sequences. Therequesting user #22 computes all the encryption sequences and combinesthem with the received vector and recovers the cleartext feeds asprepared by the servers responsive to the requested list.

Not shown for clarity, but as will be understood, an examplearchitecture for use by a node in forming the sum of the possibly manyvectors of feeds (or of photos or the like as in the example alreadydescribed with reference to FIG. 35) is as follows: a single serverbroadcasts repeatedly the entire set of d( ) vectors over a so-called“local area network” to a number of servers that each separately handlea number of requests for selected data and use the correspondingselection vectors to compile sums of those respective items broadcastthat are selected.

Turning now to FIG. 37AB, combination block diagrams and flowcharts oflow-bandwidth selection are shown in accordance with aspects andteachings of the present invention. The process steps or parts relate tothe description already provided with reference to FIG. 35 and FIG. 36.FIG. 37A shows aspects common to FIGS. 35 and 36; FIG. 37B depicts theserver-side architecture described at the end of the description of FIG.36.

Referring specifically now to FIG. 37A, the first box 3710 indicatesthat each node/server develops or obtains two keystreams per userrequesting an item and these keystreams are known to the user device.One keystream is the generated selection string, used by all servers(except not believed needed for the server that receives the sentselection string). The second keystream is that, also already describedwith reference to FIGS. 35 and 36, used to encrypt, such as by so-called“stream cipher,” the pre-output of each server.

Box 3720 indicates that the user supplies a server with the sentselection string to be in effect a substitute for that server's firstkeystream. Box 3730 describes how each server uses the first keystream,including the sent selection swing, to select the items for the groupoperation that in effect causes all but the desired items to cancel. Inthe examples, this includes inverting or not inverting based on thewhether the selection bit is zero or one. Box 3740 depicts each servercombining the pre-output of the server with corresponding secondkeystream to produce the server outputs, which are each in effectencrypted with the respective shared keys. Box 3750 is the cooperationof the servers in forming the combination under the group operation ofthe server outputs to produce the combined encrypted server output. Box3760 is the supply of the combined server output to the user and/or userdevice, which may for instance be accomplished by the servers forming aring or tree structure and/or by cooperation with other nodes thatcombine separately received streams and forward them on to users.

Referring specifically now to FIG. 37B, the first box 3780 describes theoperation of a server hub that broadcasts or streams the items that canbe selected to at least one front-end server processor. Box 3790 thenshows the front-end server processor using the group operation, such asbitwise exclusive-or in the examples, to invert those items selected forinversion and to include either the inverted or the non-invertedversion, at about the time that they are received as broadcast by thehub.

Turning now to FIG. 38ABC, a combination block diagram and flowchart ofanonymous selected data and subsets of data and user computation isshown in accordance with aspects and teachings of the present invention.The process steps relate to the description already provided for FIG. 35and FIG. 36 and a user portion for FIG. 37AB. FIG. 38A is the posting ofdata and forwarding of access to it and subsequent downloading by therecipient; FIG. 38B is the posting by a user of a set of feedidentifiers and their subsequent use in receiving feeds; and FIG. 38C isthe user device side of the embodiments described with reference to FIG.37AB.

Referring to FIG. 38A, box 3810 is the initial uploading of a data item,such as for instance a photo or other digital information, by the firstuser and for which the user receives an identifier. Box 3820 is thesending of a message, such as using the techniques described withreference to FIG. 28, by the first user to at least a second user. Themessage sent may and generally advantageously is anticipated to containkeying material at least partially allowing the second user to performdecryption of the data item once it has been downloaded. The messagesent from the first to the second user may also contain the identifierobtained through uploading the data, which identifier was used in theprocess described with reference to FIG. 37AB.

Box 3830 indicates first that the second user receiving the message fromthe first user may wait some time after receipt of the message beforesending a request, which includes a sent selection string, to a server.The sent selection string includes a desired position selected that isrelated to the identifier received by the second user.

Referring to FIG. 38B, the use shown in and described with reference toFIG. 36AB is depicted. Box 3840 includes the user and/or device sendingthrough a system, such as that described with reference to FIG. 28AB, alist of feeds; corresponding to such provision of the list, the userdevice receives a position indication, such as a for instance a sequencenumber assigned a posted list.

Referring to FIG. 38C, the user or device aspects of the processes andapparatus described with reference to FIG. 37A are included here. In box3850 the user/device computes the first keystreams for all the serversexcept for the server to which a selection string will be sent. Theuser/device combines these keystreams, such as by bitwise exclusive-oras has been described with reference to FIGS. 35, 36, and 37, to producea pre-cursor to the sent selection string. Box 3860 next shows theuser/device creating the sent selection string by flipping the bit inthe pre-cursor string in the position corresponding to the desired item.

Next 3870 is the sending of the request, including the sent selectionstring, to the particular server chosen for this purpose. One exampleway the server may be chosen, for instance, is that the choice is fixedfor all users; another non-limiting type of approach would attempt toload balance and/or provide locality.

Finally box 3880 is first the receiving of the combined output from theservers or entity they cooperate with in forming this. Then the userdevice exclusive-or's, assuming this group operation for clarity, thereceived string bitwise with the received vector and the result shouldbe the item, whether encrypted by the sender or not-encrypted by thenodes compiling the various feeds.

Turning to FIG. 39, a combination block and cryptographic schematicdiagram is provided for additive split mixing in accordance with aspectsand teachings of the present invention. The example shown includes twosenders, for clarity, three initial mix nodes and two second-column mixnodes. It will be understood, however, that any number of senders may beincorporated and that the number of initial nodes and columns may alsobe adjusted as desired, such as for instance to form a three by three orfour by four configuration of nodes.

The cryptographic embodiment described includes three main parts: theinputs to the initial column of nodes; the transformation results byeach respective node in each respective column; and the outputs providedby the final columns of nodes. Two alternate forms of input are shown,as are two alternate forms of the output; in both cases an alternate isindicted as an option, partly because the non-option case is believedbest explained first for clarity.

Referring particularly now to the inputs, they are shown as havingoriginated from users number twenty-three and eighty-five, respectively,as indicated by the user number prefix on the messages. The secondcomponent of each message is a sum, in a suitable finite group, such asfor instance, an additive group modulo a large prime, for which additivenotation is used in this figure for clarity. The second component isshown as a quotient, with the divisor equal the number of initial nodes.It is believed that when this quotient appears as a term three times,the sum that is the resulting group element will be the numerator. Thus,when the outputs of a column are summed per a respective input, twothings are believed to occur: the result is the payload c(1); and theadditive inverses of the shared keys shown, one per initial node, cancelthe shared keys added in by the initial nodes.

Referring specifically to the first or initial mixing stage, the threeexample nodes, x, y and z, are shown each as a respective row. Theoutput of each is shown enclosed in a box for clarity; the arrowsindicate that these outputs are provided as inputs to the respectivenodes of the next column or stage of mixing, as will be apparent. Itwill be appreciated that the individual user inputs are permuted in theoutputs; however, the same permutation is used for the column. In thisinitial column example with only two inputs for clarity the non-identitypermutation has been chosen. (This can be seen by noticing thesubscripts on the payload and the shared keys.) Other terms are added inby the nodes; for clarity, these are shown as a, b, and -a-b, thoughwhatever group elements that cancel may be used. In some exampleimplementations, for instance, each node computes the permutation andthe other terms from a seed known to all the initial nodes.

Referring to the second mixing stage, the results of the first stage arereceived by the respective nodes of the second column from the nodes ofthe first column, as already mentioned is indicated by the arrows. Theprocessing of what is received by the second and subsequent columns isabout the same as that by the initial nodes, apart from the shared keyterms being omitted in the later stages. Thus, for clarity again asmentioned, the a, b, and -a-b terms are added in and each node performsthe same permutation on the user input positions.

Referring to the outputs, now, it will be appreciated that it isbelieved all terms apart from the c( ) terms cancel. Again, the reasonbelieved for this is that the various shared keys were re-constructed intheir additive inverse form from the quotients in the input and thevarious additional terms were designed to cancel when respective entriesare added for a column, which also applies to the last column. It willbe appreciated that this example embodiment corresponds in input andoutput roughly to the basic mixing already described, with reference forinstance to FIG. 10 and FIG. 12, and for which numerous examples andextensions and variations have been described with reference to otherfigures here as well. It will be appreciated that these alternateembodiments illustrate the more general nature of the relatedapplications and variations described.

Some exemplary input options will now be described further. The inputoption shown on the upper right-hand side of the figure is believedapplicable where the initial nodes (or the final nodes in the case ofinverse/ack as described with reference to FIG. 28C) each have a portionof the payload. In such examples the nodes may it is believe dispensewith keys shared with users and create the a, b, and -a-b terms alreadydescribed above and shown here with prime diacritics to distinguishthem.

Some exemplary output options will now be described further. In theexample shown, a particular user or recipient is intended for each ofthe example messages. In such cases, the shared keys for that user canbe included as terms by the respective nodes, as shown. Thus, thepayload privacy can be protected as it is delivered to the user or userequipment; once received, the user can remove the shared keys, such asby in this example subtracting them. Examples of such encrypted deliveryhave already been described, such as with reference to FIG. 23. It willagain be appreciated that these alternate embodiments illustrate themore general nature of the related applications and variations describedelsewhere here.

It will be appreciated that what may be called parallel or coordinatedinstances of messages, such as those occupying the same slot in two ormore mixes that are run more or less at the same time with the samepermutations, for instance as already described with reference to FIG.28A and FIG. 28B, may also be realized with the techniques disclosedwith reference to the present figure and to FIG. 40 to be described. Itwill again be appreciated that these alternate embodiments illustratethe more general nature of the related applications and variationsdescribed elsewhere here.

Turning finally now to FIG. 40ABC, a combination block diagram andflowchart of additive split mixing is shown in accordance with aspectsand teachings of the present invention. The process steps relate to thedescription already provided with reference to FIG. 39. FIG. 40A isrelated to the case shown on the left of FIG. 39, whereas FIG. 40B andFIG. 40C relate more to the input and output options already describedwith reference to the right side of FIG. 39.

Referring specifically now to FIG. 40A and box 4010, in a first step orpart, the sender or user creates an input item that includes termsintended to be inverses of the shared keys that are known to the senderand that will be added in by the nodes.

In box 420, other inverses are included to cancel unwantedmultiplicities of the cleartext, also as already described. Box 430indicates that the user sends the sum prepared as just described ideallyas a single group element, but this may also be as multiple suchelements, depending on the coding scheme (for instance, bitwise additionmodulo two is also believed an example of a suitable group or directproduct of groups.)

Box 4040 suggests that each initial node receives the same sending fromthe user, such as a single group element, instead of sending theelements separately to each node. However, some known systems, such asthose proposed by Rabin and Rivest in a paper entitled “Efficient End toEnd Verifiable Electronic Voting Employing Split Value Representations”separately encrypt and provide that encrypted value separately to eachentry node or the like. Here, nodes each “add in,” that is combine usinggroup operations, the respective shared key or key sequence, in order tohide the payload, advantageously reducing bandwidth upload requirementsby a factor believed equal the number of initial nodes.

Box 4050 and 4060 also relate to the known systems just mentioned, aswill be understood. In particular values that cancel are added in andthe same permutation within a column are used. Which entries in theoutput correspond to the same, yet unidentified, entry in the input, isknown.

Box 4070 represents an optional improvement that reduces bandwidthrequirements by again a significant factor. The outputs are summed bythe nodes, or in cooperation with them, before being provided to atleast some other entities.

Referring to FIG. 40B, an optional improvement, already described withreference to the input option of FIG. 39, relates for example to thecase when a set of nodes, such as those making up a column on the inputside (whether the permutations and node sequences are being run forwardsor in reverse, as already explained) each have a corresponding splitportion of the cleartext that they would like sent through the system.Without using the shared keys the nodes include the split random valuesalready described and a quotient related to the payload to hide thepayload from the next column nodes.

Referring to FIG. 40C, an optional improvement, already described withreference to the output option of FIG. 39, relates to the inclusion ofshared key terms at the output side (as already mentioned, whether inforward or reverse direction, relative to other processing steps); theseterms are intended to be shared with the recipient. Thus, the recipientcan subtract the terms and recover the content in the examples shownfrom the combined message sum.

Turning to FIG. 41, a combination block and cryptographic schematicdiagram is provided for pseudonymous sender authentication in accordancewith aspects and teachings of the present invention.

Two coordinated components are shown, much as in earlier describedembodiments, such as those related to FIG. 23B and FIGS. 28A-C; however,in this embodiment instead of the identity of the user, a pseudonym isauthenticated. In some examples pseudonyms are a cryptographic functionof both the user or subscriber identity and the recipient user orsubscriber identity. Other parameters, such as a time period identifier,scope/subject identifier, or a sequence or variation number may also beincluded to provide more than one pseudonym for the subscriber pair. Insome examples pseudonyms may not be absolutely guaranteed to be unique,even though they may be so with very high probability.

Referring specifically now to the figure, in the unpermuted phase shownon the left, a second (lower) coordinated instance is introduced by thenodes without a corresponding input or payload from the sendinguser/subscriber. This component is shown as the product of factors, onesupplied by each node, such as successively during this unpermutedphase. The function j(,) is used by each node to compute its factor inthe example shown. In one exemplary embodiment this function is acryptographic function of the first argument using a secret key known tothe node whose name appears in the second argument. In the exampleshown, each node uses the sender subscriber number as the first argumentand the resulting product is a function of the subscriber number.

After the permuting phase, the s″ factors have been removed by thenodes, as already explained, and the j′ factors are shown beingsubstituted in for the t factors. The j′ function may be an independentfunction and/or use an independent key, to create separate factorsrelated to the recipient subscriber. (In other examples, the j′ functionmay be the same as j, to give the same pseudonym no matter whichdirection the message is being sent.) The product of the j and j′factors is shown as u, which is provided to the recipient. In theexample shown, this is provided privately by way of the k″ factors; inother examples, it may be provided publicly, even though differentrecipient subscriber identities may be used to allow the same sendermore than one public pseudonym.

Turning to FIG. 42, a combination flowchart and block diagram isprovided for pseudonymous sender authentication in accordance withaspects and teachings of the present invention.

Referring specifically to the figure, and the first box 4220, mixescreate and inject during an unpermuted phase a coordinated component.The values, which in the example are factors, injected into thecoordinated component by the mixes include images under a cryptographicfunction that includes keying material accessible to the respectivenodes, to produce a pseudonym that is at least very likely unique andbelieved ideally hard for other than the cooperation of nodes torecreate or check.

In box 4250, the nodes first perform a permuting phase on thecomponents. Then at least some of the nodes include cryptographicfunctions of the recipient in the example as factors. Again, thecryptographic function includes keying material accessible to therespective nodes to produce a pseudonym that is at least very likelyunique and believed ideally hard for other than the cooperation of nodesto recreate or check.

Box 4270 is the revealing of the created combined value pseudonym to therecipient, and/or to a wider audience.

Turning to FIG. 43AB, a combination block and cryptographic schematicdiagram is provided for hybrid sending in accordance with aspects andteachings of the present invention. FIG. 43A shows the preparing ahybrid sending channel; FIG. 43A shows the sending of an encryptedpayload through an established hybrid sending channel.

Referring specifically to FIG. 43A, the cryptographic schematics andblock diagram notation already introduced, such as with reference toFIG. 28A-C, is used to show the preparation of a hybrid channel. Inparticular, for each node a separate mixing is shown in the example.Each such mixing delivers to the respective node a key, which may becalled here a “mix-stage” key. For instance, key k(z) is shown deliveredto node z in the first mixing. The ellipsis between the two mixinginstances shown indicates this process is also conducted for the othernodes, as will readily be appreciated and as indicated further by thefinal mixing in the set shown.

Referring specifically now to FIG. 43B, two separate notations are usedto show each stage, one notation on top of the corresponding portion ofthe other for the same stage. The lower notation shows the compositionof encryptions and concatenation, in similar manner to that used widelyelsewhere here, with the inclusion of the concatenation or appendoperation shown as “|” sometimes referred to as “vertical bar.” Theupper notation is in cryptographic schematic and block diagram style,with corresponding expressions and ellipsis as in the notation below andwith concatenation shown as juxtaposition instead of vertical bar. Thevertical dotted lines indicate the separation of mix stages, or theprocessing by a mix, much as already elsewhere here. In particular, theoval containing a key at the upper left corner of a rectangle indicatesthe encryption with that key of the content of the rectangle.

Accordingly, as will be appreciated, the payload p shown on the rightresulted from the final mixing stage, indicate by the vertical dottedline, that takes the element on its left, the encryption of p with keyk(x) into the decryption p. The notation k(x,p) denotes the encryptionof p with key x, where here as will be appreciated x stands for a keyprovided to node x in the establishing described with reference to FIG.43A.

The structure shown to the immediate left of that just describedindicates that the key known to node y was used to place a layer ofencryption around that just described and concatenated with what may bereferred to here as a “fingerprint” or hard to invert or cryptographicone-way function of the key that may be compact but ideally avoidscollisions to at least a practical extent. The expression belowindicates the essentially the same thing using square brackets toenclose the structure on the right, as will be appreciated. The sequencedefined thus begins on the left with the outermost encryption layerformed using the key k(z) as indicated and its concatenated fingerprint.

In operation, the first node in this example, z, receives the data shownon the left of the leftmost dotted line and uses the fingerprint itcalculated of the mix-stage key already received in cleartext, duringthe establishing as already described with reference to FIG. 43A, tolocate the cleartext of that received key, by whatever data structuretechnique, such as lookup in a sorted list or more direct indexing suchas using so-called “hash table” techniques. Each node thus proceeds in asimilar manner, finding the key using the hash or fingerprint, applyingit to remove the layer of encryption, and forwarding on, so the last mixprovides the payload as its output.

It will be understood that the example shown for clarity includes mixesapplying successive decryption of layers of encryption formed by thesender. In other examples, however, the mixes may actually applyencryption using the keys provided; the recipient would in such examplesremove such layers of encryption. For instance, a sender may apply onlya single layer of encryption to the payload and provide the recipientwith the keys, or a suitable cryptographic method to generate them;layers are added by the successive mixes as the payload passes throughthem, but the recipient is able to remove the layers because of accessto the mix-stage keys.

Turning finally now to FIG. 44AB, a combination block diagram andflowchart of hybrid sending is provided in accordance with aspects andteachings of the present invention. FIG. 44A shows preparing a hybridsending channel; FIG. 44B shows the sending of an encrypted payloadthrough an established hybrid sending channel.

Referring first specifically to FIG. 44A, the establisher entity isshown in box 4410 forming keys, the mix-stage keys already describedwith reference to FIG. 43A. Forming keys is well known, such as byrandom number generators and/or cryptographic whitening and so forth. Insome such examples, these related keys are readily generated from a seedand this seed may be more convenient to store and/or communicate toother entities. Symmetric keys or stream cipher keys are believedadequate for this purpose, though other types of encryption may beapplied as will be understood.

Each mixing node is supplied one of the mix-stage keys. In the examplealready described with reference to FIG. 43A each node is supplied withan independent key and through independent mixing, thereby providing itis believed independent unlinkability. It will be appreciated by thoseof skill in the art that the keys may not be fully independent,depending on the threat models and so forth, and also that theindependent unlinkability may be diminished in some embodiments andapplications, without departing from the spirit of the invention.

Box 4430 shows the mixes cooperating in performing the separate mixingto provide the mix-stage keys to the respective mixes without revealingthe keys to other mixes and without revealing the linking between theestablisher entity and keys. Moreover, the mix-stage keys may themselvesbe unlinkable, to whatever extent, as mentioned.

Referring finally specifically now to FIG. 44B, the use of the mix-stagekeys already described in sending at least one payload in at least onedirection is shown. First box 4440 shows the sender encrypting apayload, thereby forming what may be called here a “layer.” The sendermay have established the keys and/or the sender may have received thekeys or a seed or the like for the keys from the establisher, as will beunderstood. Each successive enclosing layer of encryption formed has anassociated fingerprint, such as appended or concatenated or otherwiseincluded. The sender provides the data to a mix, such as the first mixin a cascade, for instance a fixed cascade or a cascade defined by whichnodes know the respective mix-stage keys of the sequence.

Box 4460 finally shows a mix receiving a message as input and providinga corresponding output responsive to at least a mix-stage key previouslyreachieved, such as from the establishing already described. The mixuses the fingerprint associated with the encrypted portion of the inputto find the corresponding key previously received. What may be called“matching the key” or locating it can be by looking up the fingerprintin a list or hash table or whatever data structure as already mentionedmay have been used to save it. The key can be used to decrypt the layer(or in other examples mentioned to encrypt the layer) and then forwardthe result. One example of such forwarding would be to another mix node,such as might be indicated in a header not shown or mentioned elsewherefor clarity or that may be implicit in a fixed cascade ordering. Asanother example, the result may be the final payload that is publishedor includes an optional header indicating to whom it should bedelivered.

It will be appreciated that the same channel established, such asdescribed with reference to FIG. 44A, can be used to send one or moremessages in one or both directions at whatever times and by whateverparties that may have access to the mix-stage keys. As just one example,a first party establisher may provide a seed to a second party and oneor more messages may be sent through the mixes using the mix-stage keysgenerated from the seed as described in whatever combination ofdirections and at whatever times.

Although the present invention has been described and illustrated inrespect to exemplary embodiments, it is to be understood that it is notto be so limited, since changes and modifications may be made thereinwhich are within the full intended scope of this invention as describedin the background section and claimed.

The terms and expressions which have been employed in the foregoingspecification are used therein as terms of description and not oflimitation, and there is no intention, in the use of such terms andexpressions, to exclude equivalents of the features shown and describedor portions thereof, it being recognized that the scope of the inventionis defined and limited only by the description in the background sectionand claims.

The description of the invention and its applications as set forthherein is illustrative and is not intended to limit the scope of theinvention. Variations and modifications of the embodiments disclosedherein are possible, and practical alternatives to and equivalents ofthe various elements of the embodiments would be understood to those ofordinary skill in the art upon study of this patent document. Forinstance, the first node may combine the two operations since it canknow the subscriber corresponding to a message, in some examples. Inother examples, a more general mixing is anticipated through whichmessages travel differing routes and/or not in a single batch cascadeand/or spread out over time in an at least partially randomized way.These and other variations and modifications of the embodimentsdisclosed herein may be made without departing from the scope and spiritof the invention.

What is claimed is:
 1. Cryptographic apparatus comprising: a pluralityof cryptographic node devices, each node device at a substantiallydifferent fixed location, and each node a separately-secured device, andeach node securing plural substantially different symmetriccryptographic keys; a plurality of mobile cryptographic unit devices,each unit device separately substantially controlled by a respectiveuser, and each unit device securing plural substantially differentsymmetric cryptographic keys; a substantially distinct common key, foreach distinct pair of node device and unit device, stored in therespective node device and stored in the respective unit device, and thecommon key for that respective pair of node and unit substantiallyavailable to that respective node and that respective unit exclusively;and the node devices configured to cooperate in cryptographictransformation of information received by a first one of the nodedevices from plural unit devices and the resulting information, aftercooperating transformation including by substantially all the othernodes, communicated to plural unit devices.
 2. The cryptographicapparatus of claim 1, where cryptographic node devices configured toobtain common keys from a unit device by a technique selected from theset including: public-key protocols, physical meetings, key-guns,out-of-band channels.
 3. The cryptographic apparatus of claim 1, wherethe cryptographic node devices and cryptographic unit devices configuredto advance the common key through a one-way forward-secrecytransformation at corresponding times.
 4. The cryptographic apparatus ofclaim 1, where configured for digitally mixing at least a batch of itemsof information to substantially thwart traffic analysis of communicationbetween the unit devices, comprising: one of the nodes, the entry node,first in at least a fixed cascade ordering of the nodes, includingcommunication means to receive from plural unit devices at least partsof a batch comprising plural items of information; a different one ofthe nodes from the first node, the exit node, the last node in the atleast fixed cascade ordering, including communication means to provideto respective plural unit devices at least respective parts of a batchcomprising plural items of information; intermediate communication meansat least connecting the nodes, pairwise, in the at least fixed ordering,forming a pairwise communication cascade from the entry node to the exitnode; each node including means to transform each item of information inan input batch, the input batch received over a respective communicationmeans, into an item of information in an output batch, the output batchsent over the corresponding communication means to the next node in theat least fixed ordering and by the exit node to, at least in parts, atleast some of the unit devices; the transformation means of a node forits respective input batch including means to change the order of theitems of information in the input batch into a substantiallyunpredictable, at least without secret key information available to thenode, order in its respective output batch; and the transformation meansof a node for its respective input batch including means to make thecorrespondence between the information item in the input batch, whenthey correspond to the information item in its respective output batch,substantially unrecognizable, at least without secret key informationavailable to the node.
 5. The digital mixing apparatus of claim 4, wherecommon keys included in respective information items sent by respectiveunit devices making up a batch received by the entry node and theseincluded common keys being removed from the information items by therespective nodes.
 6. The digital mixing apparatus of claim 4, wherecommon keys included in respective information items received byrespective unit devices as at least a part of a batch from the exit nodeand the respective common keys being removed from the information itemsby the respective unit devices.
 7. The digital mixing apparatus of claim4, where the real time cooperation of the nodes produces an output batchand in advance of the real-time cooperation of the nodes apre-computation produces pre-computed items of information and thepre-computed items of information then combined with respective items ofinformation in the output batch, such that the combined items ofinformation cancel the effect of at least some information included bythe nodes in the output batch and such that the real-time work of thetransformation of items by nodes is reduced by at least a factor of ten.8. The digital mixing apparatus of claim 4, where nodes are configuredfor coordinated batches, so that when at least a first and a secondcoordinated batch of information items is received as input, each itemin the first input batch is re-arranged in the first output batch to bein the same position as the corresponding item in the same position inthe second input batch is re-arranged to in the second output batch. 9.In the coordinated batch configuration of claim 8, at least onecoordinated batch comprising information items containing payload datafrom the respective unit devices and at least a different batch of thecoordinated batches made up of information items containing addressinformation of the respective recipient unit devices.
 10. The digitalmixing apparatus of claim 4, where nodes configured to make the samefixed substantially cryptographic transformation on information itemsfor each of plural batches, such that the same information item input,in whatever different positions of the plural input batches, results inthe same respective information item output for each of the pluraloutput batches.
 11. The digital mixing apparatus of claim 4, where nodesare configured to provide a reverse-path batch, corresponding to atleast a forward-path batch, and the reverse-path batch traveling throughthe nodes in the reverse node sequence of the forward-path cascadesequence and the nodes each make, with respect to the forward pathre-arrangement, the inverse re-arrangement for the reverse path batch,such that for each information item position in the forward-path inputorder, the resulting position in the forward-path output order whentaken by the reverse path as part of its input batch, results in theoriginal position in the forward-path input order.
 12. The reverse-pathapparatus of claim 11, where for a transaction the reverse-path providesa confirmation of the transaction to a unit device that initiated thetransaction, the confirmation in an information item of the reverse-paththat corresponds to the information item in the forward-path batch inwhich the transaction was initiated, such that the confirmation issubstantially assured to have only resulted from the same transactioninitiation by the unit device.
 13. The transaction apparatus of claimclaim 11, where plural separately-secured means each maintain a copy ofat least one list of images under a substantially one-way function andonly when an image is removed from a list without the addition ofcorresponding images on at least one of the at least one lists, thenodes allow a return path message indicating such.
 14. Cryptographicapparatus according to claim 1, configured for private informationretrieval, comprising: plural data items, copies of substantially allthe data item stored by each node and the data items having a maximumsize; each node, apart from a distinguished node, combining the same setof data item copies responsive to keying information corresponding tothe corresponding requesting unit device; a requesting unit devicerequest including a string communicated by the unit device to thedistinguished node, and the distinguished node combining data itemsresponsive to the string; and such that in the combination of the itemsreceived by the requesting unit device all items but the selected itemsubstantially cancel.
 15. The private information retrieval apparatus ofclaim 14, where the outputs of the nodes being combined to messages sentto the requesting unit device substantially of the same total size asthe maximum size.
 16. The private information retrieval apparatus ofclaim 14, where the nodes encrypting their respective outputscooperating with the combining of data items, so that the outputreceived by the requesting unit device can be decrypted by the unitdevice and the data item recovered.
 17. The private informationretrieval apparatus of claim 14, where a node comprises pluraldistribution devices, each distribution device communicating with pluralrequesting unit devices, the distribution devices additionally connectedto a broadcast network, the distribution devices each combining dataitems as broadcast over the broadcast network and responsive to requestsfrom requesting unit devices.
 18. A cryptographic system comprising: aplurality of cryptographic node devices, each node device at asubstantially different fixed location, and each node aseparately-secured device, and each node securing plural substantiallydifferent symmetric cryptographic keys; a plurality of mobilecryptographic unit devices, each unit device separately substantiallycontrolled by a respective user, and each unit device securing pluralsubstantially different symmetric cryptographic keys; a substantiallydistinct common key, for each distinct pair of node device and unitdevice, stored in the respective node device and stored in therespective unit device, and the common key for that respective pair ofnode and unit substantially available to that respective node and thatrespective unit exclusively; and the node devices in a first stepprocessing cryptographic transformations of information received by afirst one of the node devices from plural unit devices and the resultinginformation, after cooperating transformation processing including bysubstantially all the other nodes in corresponding steps, communicatedto plural unit devices in a final step.
 19. A cryptographic methodcomprising: a plurality of cryptographic node devices, each node deviceat a substantially different fixed location, and each node aseparately-secured device, and each node securing plural substantiallydifferent symmetric cryptographic keys; a plurality of mobilecryptographic processes, each mobile process separately substantiallycontrolled by a respective user, and each mobile process securing pluralsubstantially different symmetric cryptographic keys; a substantiallydistinct common key, for each distinct pair of node device and mobileprocess, stored in the respective node device and stored by therespective mobile process, and the common key for that respective pairof node and mobile process substantially available to that respectivenode and that respective mobile process exclusively; and the nodedevices in a first step processing cryptographic transformations ofinformation received by a first one of the node devices from pluralmobile processes and the resulting information, after cooperatingtransformation processing including by substantially all the other nodesin corresponding steps, communicated to plural mobile processes in afinal step.